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Software  Engineering  to  our  Planning  Horizon1 


Luqi  and  Manfred  Broy 


The  Army  Research  Office,  National  Science  Foundation,  Office  of  Naval  Research,  and 
the  Defense  Advanced  Research  Projects  Agency  sponsored  the  1998  Monterey  Workshop  on 
Engineering  Automation  for  Computer  Based  Systems. 

This  workshop  is  the  6th  in  a  series  of  international  workshops  with  the  general  theme  of 
increasing  the  practical  impact  of  formal  methods  for  software  and  systems  engineering.  The 
workshop  took  place  in  Carmel,  California  late  1998,  hosted  by  the  Naval  Postgraduate  School. 

Since  1990,  the  previous  workshops  in  the  series  focused  on  real-time  and  concurrent 
systems,  software  merging  and  slicing,  software  evolution,  software  architecture,  and  require¬ 
ments  targeting  software.  This  workshop  focused  on  engineering  automation. 

The  objectives  of  the  workshops  are  to  encourage  interaction  between  the  research  and 
engineering  communities,  exchange  recent  results,  assess  their  significance  and  encourage 
transfer  of  relevant  results  to  practice,  communicate  current  problems  in  engineering  practice  to 
researchers,  and  help  focus  future  research  on  directions  that  address  pressing  practical  needs. 

Over  the  past  years,  we  have  witnessed  a  slow  but  steady  decrease  in  the  gap  between 
the  theoretical  and  practical  sides  of  the  software  engineering  community.  We  hope  that  this 
trend  will  continue  and  will  accelerate  improvements  in  the  state  of  software  engineering  prac¬ 
tice  and  theory.  Software  problems  have  been  quite  visible  to  the  public  due  to  spectacular 
disasters  in  space  missions  or  telephone  black  outs  and  are  receiving  increasing  attention  with 
the  nearing  Y2K  deadline.  It  is  a  good  time  to  demonstrate  concrete  improvements  in  our  dis¬ 
cipline. 

The  continued  doubling  of  computing  speed  and  memory  capacity  every  18  months 
implies  that  the  only  constancy  for  large  distributed  systems,  technology,  tactics  and  doctrine 
may  well  be  the  idea  that  change  is  always  inevitable.  The  dynamic  aspect  of  systems  is  not 
supported  by  current  practice  and  is  seldom  emphasized  in  current  research.  Software  evolu¬ 
tion  research  is  extremely  important  for  achieving  modifiable  and  dependable  systems  in  the 
future.  Improved  methods  for  reengineering  are  also  needed  to  bring  legacy  systems  to  the 
condition  where  they  can  benefit  from  improvements  in  software  evolution  technology. 

Thirty  years  ago,  when  the  term  software  engineering  was  coined,  there  was  lack  of 
theoretical  foundation  for  many  practical  concepts  in  computing.  That  is  no  longer  true.  A  solid 
body  of  foundational  work  is  available  now  that  addresses  many  challenging  issues  related  to 
software  and  computing,  including  specification  techniques  for  systems  and  data,  logical  calculi 
for  concurrent,  distributed,  and  real-time  systems,  logical  concepts  related  to  interactive  sys¬ 
tems,  and  formal  models  of  programming  language  semantics  with  a  variety  of  inference  sys¬ 
tems. 

The  challenge  is  to  put  these  results  to  work,  to  develop  theory  that  better  supports 
engineering  needs,  and  to  improve  practice.  This  will  require  cooperation  and  a  concerted  effort 
from  both  theoreticians  and  practitioners.  We  will  need  advances  in  education  and 

1  This  research  was  supported  by  ARO(MIPR8GNPSAR042),  NSF(CCR-98 13820),  ONR(N0001499WR20019), 
SPAWAR(N6600 1 98WR00438). 
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Engineering  Automation  for  Computer  Based  Systems1 

Luqi 

Computer  Science  Department,  Naval  Postgraduate  School,  USA. 


1.  Introduction 

Software  development  capabilities  lag  far  behind  society’s  demands  for  better,  cheaper,  more  reli¬ 
able  software.  Since  the  gap  is  so  large,  and  widening,  it  is  unlikely  that  "business  as  usual"  will  be 
able  to  meet  this  need.  Engineering  automation  based  on  sound  and  scientific  methods  appears  to  be 
our  best  chance  to  close  the  gap. 

This  is  the  sixth  in  a  series  of  workshops  whose  common  goal  is  helping  to  increase  the  practical 
impact  of  formal  methods  in  software  development.  These  workshops  have  succeeded  in  gradually 
bringing  the  theoretical  and  practical  sides  of  the  software  engineering  community  closer  together, 
focusing  them  on  fulfilling  the  promise  of  scientific  improvement  of  software  engineering  practice.  The 
progress  made  in  this  direction  at  this  workshop  was  larger  and  more  readily  apparent  than  in  previous 
years,  giving  us  hope  that  the  effort  will  eventually  succeed. 

The  remainder  of  this  paper  is  organized  as  follows.  Section  2  restates  the  main  premises  of  the 
workshop.  Section  3  gives  an  overview  of  the  papers.  Section  4  summarizes  some  of  the  discussion  at 
the  workshop,  and  Section  5  presents  some  conclusions. 

2.  Premises  of  the  Workshop 

The  main  premises  of  the  workshop  are  that  mathematics  and  formal  methods  can  help  solve 
practical  problems  in  the  engineering  of  computer-based  systems,  and  that  engineering  automation  is  a 
promising  way  to  accomplish  this. 

We  use  a  broad  definition  of  "formal  method."  Webster’s  Dictionary  says  that  formal  means 
definite,  orderly,  and  methodical;  that  method  means  a  regular,  orderly,  and  definite  procedure;  and  that 
model  is  a  preliminary  representation  that  serves  as  a  plan  from  which  the  final,  usually  larger,  object  is 
to  be  constructed.  Thus,  to  be  formal  does  not  necessarily  require  the  use  of  logic,  or  even  of 
mathematics. 

In  computer  science,  the  phrase  formal  method  has  taken  on  a  narrower  meaning,  referring  to  the 
use  of  a  formal  notation  to  represent  system  models  during  program  development.  An  even  narrower 
sense  refers  to  use  of  a  formal  logic  to  express  system  specifications,  and  proofs  to  check  correctness  of 
implementation  code  -  i.e.,  that  it  satisfies  the  specification. 

The  broader  definition  of  formal  method  is  appropriate  to  this  workshop  because  it  fits  the  theme 
of  engineering  automation.  Processes  need  to  be  definite,  orderly,  and  methodical  to  be  successfully 
and  reliably  automated.  Thus,  formalization  of  engineering  processes  in  this  broad  sense  is  a  prere¬ 
quisite  for  engineering  automation. 

The  narrower  sense  of  formal  method  -  checking  whether  or  not  the  code  satisfies  a  particular 
requirement  specification  in  a  formal  logic  -  is  inappropriate  for  this  purpose,  because  of  the  well 
known  fact  that  the  majority  of  software  defects  are  requirements  errors  (see  the  paper  by  Berry  in  this 
Proceedings).  If  the  specification  is  wrong,  we  do  not  want  code  that  satisfies  the  specification. 

The  broader  interpretation  of  formal  method  opens  the  door  to  other  approaches,  such  as  require¬ 
ments  elicitation  via  prototyping  and  the  automatic  synthesis  of  correct  code  from  requirements  models 

1  This  research  was  supported  by  ARO(M1PR8GNPSAR042),  NSF(CCR-98 13820),  ONR(N0001499WR20019). 
SPAWAR(N6600 1 98 WR00438). 
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and  model  checking  that  can  provide  proofs  abom  infimre  ?!  for  “mbining  deductive  inference 
methods.  Cleave, and  and  Sims  presem  merhS? “  “  sys“ms  “ai"8  =l*orirhmic  finite  stare 

generated  model  checkers.  Narasimba  Cleave  nH  /T°  th  efficiency  of  generic,  automatically 

J1<jfel'C^kjnJProcedure  for  probabilistic  systems  Kwa/ Ler^ndS  ^Ti?61’  semantics*  and 

bolic  schedul  ability  analysis  that  links  to  efficient  equation  ^  c°k°Isky  gIve  a  me(hod  for  sym- 

Of  formal  methods.  Polak  reports  a  succesffulTnnfic^tir^  CXperiences  «  the  application 

•zed  domain  (satellite  control  systems)  and  analJ?  a  °f  automatlc  Program  synthesis  in  aspecial- 
and  Wirsing  formalize  a  tbe  reasons  for  the  P^jecfs  success.  Kosiuczenko 

sage  sequence  charts)  using  timed  rewrite  logic and Jftef1"'*'}™  distributed  systems  (mes- 
mg  it.  revealing  a  fault.  Gelfond  anS  WatS  describe^  llTl™  *  **  3  Specificati°n  by  execut- 
monotomc  semantics  to  realize  ^  °I  ^  ***""»  with  non' 

tion  in  the  presence  of  multiple  equipment  failures)  Vnlif  f°  f  £  P  ex  domain  (space  shuttle  opera- 
cation  of  the  higher  order  logic  ? ?f  describe  successful  apph- 

safety-critical  domain  (industrial  control)  Gafni  Feldman  "  Tv\  °f  function  blocks  S  a 

language  for  large  scale  applications  Z  exoWn  Ihf  i  "  .  ,nd,  Y.ehudai  present  a  real-time  design 
control).  Cooke  S£*  ^  ^  ™  an  exampl«  («3S 

with  applications  to  data  mining.  Zhang  LeeP  Friedel  and?  concurrency  m  data  parallel  computation, 

erating  facts  from  raw  data  to  provide  decision  sunm^  f  ^  SCnbe  statisticaI  methods  for  gen- 
phased  array  antennas).  P  PP°rt  for  an  engmeering  task  (diagnosis  and  repah  pf 

puting,  and  that  thiSP  chaSgf  hS  £-retchin?effecte  *e  n3tUre  °f  COm' 

noc^poSfp^ t  a^safirs The  t  i<,e*s  “e  s 

machm.  is  no,  fixed  advanCe,  and  oj  ,ha  S,  ?  f  *  ?'  inP“l  »  “  i««™«ive 

ha,  point  A  difference  in  expressive  power  due  lo  thi?  rsZ!  T  P'J°<l““d  by  ““  machine  up  to 
leads  io  different  kinds  of  formal  models,  such  £  and  dT.‘ '  ,™!r  °f 

as  co-induction,  which  are  relevant  to  the  analysis  of  oDfn  fextfWhf  'f  *  m°deS  °f  reasoninS.  such 

““ currem  pracfe  of  °bj“'  ^ 
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as  well  as  some  controversy  about  the  details  and  their  philosophical  interpretation. 

4.  Summary  of  the  Discussions 

J*16  National.  Science  Foundation  is  considering  the  impact  of  the  PTAC  reoort 
(httpy/www;ccic.gov/ac)  and  its  impact  on  national  research  prioriUeaf  as  summariaadbelow  Sa 

^aKhpS^Sod'r:  W1S  10  mak'  S°!mm  re“arCh  a"  abS0,UB  n.«  four  major 

(1)  Software 

Scalable  information  infrastructure  (networking) 

High  performance  (peta-flops)  computing,  including  software  R  &  D 
Socio-economic  and  workforce  impacts 

,The  *ePort  finds  that  software  demand  exceeds  the  nation's  capability  to  produce  it  that  we  must 

and  thTtht  0n/r^i  e  SJftWare’  that  technoloSies  to  build  reliable  and  secure  software  ^re  inadequate 
and  that  the  nation  is  under-investing  in  fundamental  software  research.  " 

The  report  makes  the  following  recommendations: 

Fund  fundamental  research  in  software  development  methods  and  component  technology: 

Sponsor  a  national  library  of  software  components  in  subject  domains; 

Make  software  research  a  substantive  component  of  every  major  IT  research  initiative;  and 
Fund  fundamental  research  in  human/computer  interfaces  and  interactions. 

rw  , ^elCVan-  resTearch  initiatives  include  ASCI  (Accelerated  Strategic  Computing  Initiative)  and  NGI 
Search^yf  f°Vnt>ernet  '-  ^  lnt6met  making  **  next  step>  with  maJor  implications  for  software 
future  cont Jxt  day  $  enVir°nment  15  not  tomorrow’s-  and  many  issues  need  rethinking  within  the 

m  .  S  a  u?que  p0int  u"  IT  hist0ry:  agendas  ***  beins  set  and  recommendations  are  being 

d  a  research  agenda,  a  plan  for  research  management,  and  action  to  build  public 
pport.  Consequences  of  not  acting  include  negative  economic  impact  and  loss  of  global  leadership 

aherefrePnledtoeSS'  ^  ^  ^  ^  “*  ^  ”ntly  able  t0  meet  the  demand  f°r  software.  We 

(1)  empower  end-users  with  domain-specific  tools  that  create  software; 
make  component-based  development  a  reality; 
automate  software  engineering  processes;  and 
produce  more  well-trained  professionals. 

»;  cv^"°ther  1SfaUe. 1S  *e  cannot  Produce  high-confidence  systems,  and  cannot  even  produce  rou- 
tine  systems  routinely.  We  therefore  need  to: 

(1)  understand  what  works  and  what  does  not; 

(2)  understand  the  science  of  software  construction;  and 

(3)  create  a  discipline  of  software  engineering. 

n..Th*  proble™s  identified  in  the  PITAC  report  have  many  facets,  including  unresolved  practical 
problems,  rapid  change,  immaturity  of  the  science,  a  gap  between  theory  and  pracdce,  fragmentation  of 
me  research  community,  and  inadequate  infrastructure  for  technology  transfer. 

i  h0ir°r  St0iy  iS  that  We  Can  not  afford  t0  buiId  software  systems  using  current  tech¬ 

nology.  Inis  has  been  true  for  many  years  despite  improvements  in  the  state  of  practice  We  have  not 
made  a  convincing  case  that  we  have  done  much.  Some  of  the  reasons  for  this  are  increasing  demand 
ana  rapid  change,  lack  of  effective  technology  transfer,  and  lack  of  the  right  kind  of  science. 

The  practice  of  software  engineering  is  moving  very  fast,  in  an  attempt  to  keep  up  with  demand 
and  stay  ahead  of  the  intense  competition.  Time  to  market  is  vital  in  the  commercial  world  Many 
developers  jump  on  aggressively  marketed  software  fashions,  although  they  often  include  ad  hoc 
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methods  and  worst  practices  along  with  some  improvements. 

improvement  over  preiiouspmcti^  Ne^rking  com^unTcado  ^  JaVa  i$  an 

mg  m  reusing  resources.  Commercial  systems  enainerrino  •  f  a  n  coming  together,  and  succeed- 
professionals  in  about  ten  years.  °  8  1S  imProving.  We  can  successfully  educate 

inconclusive  results.  The  seTamkro^C+H-1  remdnTcri  UML-  !“?.  ^  benefit  °f  lots  of  talent  with 
although  it  is  still  difficult  ^cTm^e^ompoiwnte^ork  tog^her.^*3^  C°mP°nent  teChn0l°8y  is 

that  theoretical  results  take  too^muchUme  and^sTto  incomorateTf6"1^  -eSU,tS  “*•  imPr.actical  and 
competitive  world.  Some  parts  of  the  theoretical  comoutinefrn  -°  Practlce’  especially  in  a  highly 

engineering  is  irrelevant.  The  result  is  ineffective  tech™!  °  mmflty  take  the  attitude  that  practical 
weak  scientific  basis.  ineffective  technology  transfer  and  engineering  practice  with  a 

there  aTu^pTy^^  or^blelf  ^  ^  ^  ^ 

tions  flowing  down  the  supply  chain  This  should  be  a  m  r  0WJn°  ^  suPPty  chain  and  solu- 
Currently,  it  is  We  can^foricha^  jf£J£  * “^7“'  **  *K*m  pr°“- 

proble^LTrt^T/rf  lZ!e^^,LTc^ei7Thri'\0f 

our  educational  systems.  Many  issues  that  arise  in  en<rin™  i  d  b  ^ed  by  the  current  practices  of 
scientific  community.  There  is  growing  awareness  of  these  pr3CdC.e  have  not  been  addressed  by  the 

community  to  address  them  by  developing  a  more  robust'  Trid*- “f1?®?1"?  reSOlVe  in  the  scientific 
engineering  technologies.  P  g  °b  st  d  Pnncipled  basis  for  future  software 

insteaJspealTof  and  Man ^^tfraL'Z".?  H°  7”"”  *“S  We  should 

ratio,”  a  rational  path.  It  is  not  convincing  to  say.  "We  w e  on  Uie  riSht  dd-1?  U""  f°’™th°d  is  "vi» 
are  what  matters."  A  shift  of  paradigm  is  now  needed  The  „  r!  g?  because  math  and  formulas 

ing  that  result  are  what  matter  For  nro<rre««  in  •  •  ?U.a  iy  die  result  and  the  cost  of  produc- 

solution  must  be  a  ”  1  «  b  “Sential  automate  the  process.  Ae 

build  an  advanced  system,  it  will  be  at  a  cost  of’nm  ddngit  again™'  W*  Sdmit  that’  even  if  we 

understand  and  developrth™lyciInc?needed™toSbrin2rthrt0m-ated  .engineering,  our  community  needs  to 
ful  to  the  degree  that  ft  confutes  to to -°  *“*  IeVeL  Formalizad°"  is  use- 
ing  processes.  thJS  8°al  by  enabl,ng  automat>on  or  systematization  of  engineer¬ 
engineering  ST  ^o^a^^T  °I  *"***  wbile 

failures  -  as,  for  example,  in  seismology.  A  finer  and  learns  mostly  from 

is  needed  to  achieve  progress.  Many  good  ideas  have  been  n  ween  mathematics  and  empirical  science 
ate  success.  The  only  bto  feSKZL  J  been  proposed,  but  often  without  a  plan  to  evalu- 

the  abstract  can  not  be  realized  in  practice  8Good  emniriffT*  SC,e.nce’  .Many  ldeas  *at  sound  good  in 
been  able  to  do  it  well  so  faT  P  1  C°mpUtCr  Science  is  needed.  but  no  one  has 

theoretical  science.  Recognition  o^  thrcate’gorv^np/nL U,SefUl  ^  dl*tlaguish  en^ineering  science  from 

jng  agencies  typically  support  science  rather  than  engineering^  IT  becau?e  research  fo"d- 
improve  the  capabilities  of  oracticina  pnain^rc  *ru  *  -  a  m  of  enojneenng  science  is  to 

our  understanding  of  Smpute  AutomS IT,  ™  °f  C°mp^  U  » ta>P«>ve 

sanly  for  theoretical  computing  science.  pnmary  goal  for  engtneenng  science,  but  not  neees- 

ing  Z  c°"-u, in  ?e  ,on8  tenn  10  s0fM“e  -s™- 

engineers.  However,  7  T  *  m d  “  »  **  for 

relevant  resul,  from  ctjumr 

theoretical  advances  are  often  modeling 
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inescapable  in  practical  engineering, 
for  progress. 


These  issues  are  in  the  realm  of  engineering  science,  and  are  vital 


xt  x  nCtd  technol°Sy  transfer  from  relevant  new  engineering  science  to  make  things  work 
Nobody  has  the  responsibility  for  this  now.  There  should  be  an  "Expedition  Center"  to  envision  what 
the  world  is  going  to  be  like  in  100  years,  and  a  "Transfer  Center"  to  transform  those  visions  into  real- 
ity.  We  have  to  be  careful  about  what  kind  of  technology  we  transfer:  it  must  be  relevant  to  practical 
problems.  There  is  much  irrelevant  material  from  former  type  theoretical  computer  science  and  others* 
e,g.,  How  do  you  get  a  theorem  to  find  oil? 


The  various  parts  of  the  community  must  interact  more  closely  than  they  have  in  the  past  to 
achieve  practical  impact.  Software  isolation  is  a  problem.  Much  software  is  connected  to  communica¬ 
tion,  hardware,  and  other  components.  If  we  do  not  include  these  components,  we  have  not  solved  the 
problem.  Results  from  other  disciplines  are  relevant  also.  Software  development  is  a  special  case  of 
product  development.  Software  is  hard  because  it  is  abstract;  it  cannot  be  visualized.  We  can  leam 
much  from  design  theory  and  product  management. 


B  change  affects  the  scientific  community  as  well.  The  nature  of  computing  may  change  sub- 
stantially  in  the  21-st  century.  For  example,  new  models  of  interactive  computing  and  quantum  com¬ 
puting  are  on  the  horizon.  Today’s  computing  environments  can  not  and  will  not  be  the  environments 
of  tomorrow.  Computing  is  a  relatively  new  science.  There  is  opportunity,  but  also  a  need  to  educate 
people  about  what  computer  science  is  and  what  it  can  be.  There  is  also  need  for  periodic  reality  checks 
to  ensure  feasibility  of  long-term  visions.  These  exercises  can  help  improve  the  credibility  of  our  field, 
can  provide  course  corrections  for  research  agendas  and  can  evaluate  readiness  for  technology  transfer 
as  we  leam  more  about  what  can  be  done  at  what  cost.  DARPA  and  other  agencies  have  challenge 
problems  that  could  serve  these  functions.  For  example,  the  automatic  theorem  proving  community  has 
a  standard  set  of  benchmark  theorems. 


There  is  a  tension  between  long-term  goals  and  short-term  goals.  Funding  agencies  require  that 
goals  be  achieved  on  a  yearly  basis.  This  is  an  issue  that  must  be  faced  by  all  branches  of  science,  not 
just  in  computing.  We  can  ask  how  the  issue  is  handled  in  other  disciplines,  such  as  particle  physics. 
Physics  has  a  history  of  setting  up  visionary  programs.  In  Italy,  72  percent  of  money  for  basic  science 
goes  to  physics,  and  only  1.7  percent  goes  to  information  science.  Why  is  this  -  a  good  part  of  the 
answer  is  that  the  physics  community  behaves  in  a  political  way,  i.e.,  it  has  a  lobby.  They  say,  "We 
have  this  great  vision.  We  need  Congressional  funding  for  astrophysics,  etc.",  and  then  set  up  a  lobby 

and  get  real  money.  We  need  to  develop  a  similar  vision  and  agree  to  work  together  toward  that 
vision. 


In  computing  science,  we  have  not  agreed  on  the  goals.  This  has  been  aggravated  by  the  rapid 
rate  of  change,  which  has  spawned  computing  schools  of  thought,  and  intense  competition  for  scarce 
research  support.  We  need  to  identify  our  goals  and  stick  together,  instead  of  "dissecting  ourselves  to 
death."  Computing  research  does  not  have  to  be  a  zero  sum  game.  The  goals  identified  in  PITAC 
report  are  a  good  starting  point  for  developing  a  shared  agenda  for  the  entire  computing  community. 

Computing  is  the  most  successful  technical  discipline,  in  that  it  has  come  to  relevance  and  has 
been  applied  in  a  relatively  short  time.  Decidability  and  computability  ideas  appeared  only  at  the 
beginning  of  this  century.  We  had  a  vision  of  software  engineering  in  1968,  but  people  were  not  aware 
of  how  much  is  hidden  behind  that  vision.  The  digital  point  of  view  brought  in  a  whole  new  view  of 
the  world,  as  opposed  to  physics.  There  is  a  basic  difference  between  the  root  of  physics  and  the  root 
of  computer  science.  The  foundations  of  computer  science  are  very  simple  -  i.e.,  Turing  machines 
suffice,  with  some  modifications.  NP  completeness  is  not  the  most  central  problem.  The  real  problems 
come  on  the  macro  level,  in  building  systems  and  with  human  factors.  The  roots  of  physics  are 
different,  more  involved.  The  theory  of  digital  models  may  become  much  more  than  it  is  today. 

We  should  be  happy  to  work  in  a  scientific  field  that  has  such  a  high  level  impact.  We  should 
also  understand  that  there  is  a  real  push  in  progress,  and  appreciate  that  scientific  push.  What  we  have 
done  wrong  is  to  engage  in  too  much  infighting,  much  of  which  is  due  to  not  understanding  the  inherant 
positions  imposed  by  the  disciplines  of  our  colleagues.  What  we  have  gained  over  the  last  20  years 
could  not  have  been  done  without  deeper  understanding.  What  we  actually  do  in  practice  is  not  called 
formal  methods,  yet  we  have  made  more  progress  than  we  realize.  It  is  important  to  make  the  field 
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more  transparent.  We  are  just  at  the  beginning. 

5.  Conclusions 

p*™  ZSTSlmSSSTZ  T  -***  sapp°n  ,he 

the  circumstances  under  which  such  gainc  ran  hr  ,r-.r  a  ^  3  ®ains‘  Some  of  the  papers  detail 

viding  a  snapshot  of  the  current  state  Ke  rn  i„  *'t?a  “tIe,"ly  kn0Wn  ttCh"i^  P"=- 

zzifgtt For  ,he  - 

mMgmmm 

mmmmmms- 

.n  this  direction,  and  to  demonstrate  the  p'racica,  implc” ”f  Z  p^ta  .^SSd'3!’ 
“hothTe  ““  "  “  WMk  L  *  ™ SS 
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ABSTRACT 

The  paper  defines  formal  methods  (FMs)  and  describes  economic  issues  involved  in  their  application.  From  these  con¬ 
siderations  and  the  concepts  implicit  in  “No  Silver  Bullet”,  it  becomes  clear  that  FMs  are  best  applied  during  requirements 
engineering.  A  explanation  of  why  FMs  work  when  they  work  is  offered  and  it  is  suggested  that  FMs  help  the  most  when  the 
applier  is  most  ignorant  about  the  problem  domain. 

Keywords:  Formal  Methods,  Verification,  Refutation,  Economics,  Requirements  Engineering,  Second-Time  Phenomenon, 
Ignorance  Hiding,  Evangelists 

1  INTRODUCTION 

This  paper  is  something  that  I  have  been  meaning  to  write  for  some  time  now.  I  have  been  giving  a  talk  whose  title  is 
that  of  this  paper  to  a  variety  of  audiences.  In  each  case,  the  discussion  generated  was  interesting  and  supplied  more  material 
for  the  ever  growing  talk.  When  I  received  the  invitation  to  attend  the  Monterey  Workshop  on  Engineering  Automation  for 
Computer-Based  Systems,  I  saw  an  opportunity  to  present  the  talk  to  an  audience  of  almost  entirely  formal  methods  people, 
including  some  of  the  pioneers.  The  talk  was  much  better  received  than  I  thought  it  might  be  given  its  controversial  nature. 
Moreover,  all  speaking  participants  at  the  workshop  were  required  to  produce  a  paper  for  the  proceedings.  The  paper  that  I 
wanted  to  write  is  the  result. 

Because  the  paper  represents  more  my  personal  opinion  rather  than  some  rigorously  established  scientific  conclusion,  the 
paper  uses  first  person  when  referring  to  the  author. 

I  have  benefited  particularly  from  an  electronic  discussion  in  1995  with  Martin  Feather. 

1.1  Author’s  Background 

My  current  area  of  research  is  Requirements  Engineering  (RE)  [5].  The  focus  of  this  area  is  on  how  to  get  requirements 
for  software-intensive  computer-based  systems  (SWICBSs).  It  is  now  recognized,  as  is  explained  in  the  body  of  this  paper, 
that  determining  the  requirements  for  SWICBSs  is  the  hardest  part  of  their  development,  and  difficulties  in  determining  these 
requirements  are  the  source  of  a  vast  majority  of  errors  found  in  delivered  SWICBSs.  The  RE  area  is  interested  in  under¬ 
standing  why  a  method  of  determining  requirements  works  when  it  does  and  why  a  method  of  determining  requirements  fails 
when  it  does. 

1.2  Outline  of  Paper 

This  paper  starts  of  with  a  brief  definition  of  FMs.  It  then  gives  some  feeling  for  the  economics  of  applying  FMs  to  the 
development  of  SWICBSs.  Fred  Brooks’s  observation  of  "No  Silver  Bullet”  is  recalled  for  what  it  says  about  the  difficulty  of 
determining  SWICBS  requirements.  The  paper  offers  that  the  most  useful  time  to  apply  FMs  is  in  the  requirements  engineer¬ 
ing  phase  of  SWICBS  development.  Not  all  applications  of  FMs  lead  to  high  quality  SWICBSs.  However,  when  they  do 
succeed,  there  appear  to  be  two  factors  working  for  that  success,  the  second  time  phenomenon  and  qualities  of  the  people 
who  push  for  and  engage  in  FMs. 


♦with  apologies  to  James  H.  Fetzer  [14] 

§  on  sabbatical  leave  from  Computer  Science  Department,  Technion,  Haifa  32000,  ISRAEL,  with  part  of  work  done  at'GMD 
FIRST,  Rudower  Chaussee  5, 12489  Berlin,  Germany 
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So  as  not  to  lose  readers  who  believ?  in  bm,  „„ a  ■_ 

that  I  believe  in  FMs  and  use  them  when  appropriate.  niMd*I!^<fothiS  “  argUing  against  theI*' use.  please  consider 
to  clients’  SVVICBS  development  problems,  including  for  secure  operating  SdlS  m  technol°gy  and  applies  FM 

on  the  underlying  theoty  of  one  FM  a  long  time  ago  [3]  The  ms£  5  S Tl'r  ‘  dld  s°"“  <to'«*™Mtl  work 

rsr bkmsc °f* < — a/pU 

2  DEFINITIONS  OF  FMs 

the  *5  d'™,077  ,of  a  SWICBS,  in  otde,  to  improve  the  quality  „f 

FM  claims  is  an  FM.  If  I  have  negLed  to  include  one,  myTpXfc put" ^  rea'm  °f  ™s  *"*»»  working  in 

Setr*  F°r  f“"et  diSCl,SSi0nS’  s“  ,he  PX**  by  M,  S  W°t 1,?22  lnClUde  *  referc"“  •» 

There  are  three  main  groups  of  FMs  verification  intone?,,*  ^  ’  •  ln£  ”8,22,26],  and  papers  cited  therein 

group  is  described;  its  strengths,  weaknesses  and  costs  ^e  considered  ^  *****  °f  ^  Pr°blem’  and  refutatioa-  Each 

2.1  Verification 

proved  to  be  a  correct  realization  SVspLtS  °f  &  SWICBS  can  be  formally 

sistent  with  a  formal  specification.  Rarely,  however  is  the  full  nmnfr!  •  A  *T  tnct  ^  sPeakmg,  the  code  is  proved  con- 
as  their  goal  the  production  of  at  least  one  part  of  a  full  proof  of  correctness  Xitffinrtf in  tWs  group  3,1  have 
mality  and  completeness.  Here,  by  “completeness”  is  meant  that  nS  ?  *  gr°Up’ there  305  many  levels  of  for- 

of  the  FMs  of  this  group  can  be  characterized  2  ory .  Some 

means  partial  through  complete”,  “C”  means  “complete”,  and  “P”  means  “partial  ^  ^  ““  Uble’  **  n°tati°n  “Pf4C” 

formal  specification  of  requirements 

verification  of  consistency  and  basic  correctness  of  requirements  specification 
rormal  specification  of  design 

verification  of  consistency  of  requirements  and  design  specifications 
formal  specification  of  code 

verification  of  consistency  of  (requirements),  design,  and  code  specifications 
code 

verification  of  consistency  of  (requirements,  design,  and)  code  specifications  and  the  code 

Table  1 

^  vr  *>  * by  virtue  „f 

“hasic  correctness"  means  verification  j.1  ‘'V"'S  Pro0f' J"  ^  l 

the  correctness  criterion,  e.g.,  security.  q  P  "  P  satisfies  any  available  independent  specification  of 

7  are  carried  out  with  no  verificatio^Rtthl^the1  ^wTof  °f  ,leVels'  Sometimes  only  Level  1  and  Level 

SWICBS  to  be  developed  before  8 ,0WS  mudl  t0  be  learned  3bout  the 

informal,  natural  language  specification  is  written  Sornetimpc  n  ?  T  ,  -U?  more  IS  ^earnec^  this  way  than  when  only  an 


1 

2 

3 

4 

5 

6 

7 

8 


P«-»C 

PoC 

Pf4C 

PoC 

Pf4C 

Pf-»C 

C 

P<->C 
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2.2  Intensive  Study  of  Key  Problems 

The  second  group  of  FMs  are  the  intensive  mathematical  study  of  one  or  more  difficult  aspects  of  the  SWICBS.  These 
are  an  attempt  to  avoid  the  heavy  costs  of  the  verification  FMs.  Rather  than  specifying  the  entire  SWICBS,  only  the  difficult 
or  problematic  parts  of  the  SWICBS  are  considered.  For  example,  if  the  job  is  to  build  a  secure  operating  system  that  guaran¬ 
tees  that  pnly  authorized  users  gain  access  to  any  specific  file,  instead  of  specifying  the  whole  operating  system  and  proving 
its  security,  one  could  focus  on  the  security-relevant  portion  of  the  system  at  the  specification,  design,  or  code  level,  or  at 
some  combination  of  these.  While  this  focusing  is  considerably  cheaper  than  dealing  with  the  full  system,  it  is  fraught  with  a 
serious  danger  of  overlooking  something  that  is  security  relevant  One  cannot  be  certain  that  the  ignored  portions  of  the  sys¬ 
tem  are  not  security  relevant,  that  they  do  not  impact  and  they  are  not  impacted  the  parts  designated  as  security  relevant  and 
therefore  under  study.  To  prove  that  the  ignored  parts  are  not  security  relevant  turns  the  FM  into  a  costly  verification. 
Nevertheless,  as  one  gets  experience  with  a  class  of  applications,  he  or  she  becomes  more  certain  about  what  can  safely  be 
ignored. 


1  C  study  of  one  difficult  aspect  of  requirements  e.g.,  security,  safety 

2  C  study  of  one  difficult  aspect  of  design 

3  G  study  of  one  difficult  aspect  of  code 

Table  2 

I  would  classify  into  this  group  any  development  in  which  theoretical  knowledge  is  used  to  make  the  development  of  a  pro¬ 
gram  more  systematic.  The  most  common  example  of  this  phenomenon  is  compiler  writing,  which  borrows  heavily  on  the 
theory  of  phrase-structure  grammars  and  has  spawned  its  own  collection  of  theory. 

The  rules  of  thumb  that  I  have  heard  are  that  these  intensive  study  FMs  drive  the  development  cost  up  from  2  through  5 
fold,  depending  on  the  complexity  of  the  problem  and  depending  on  how  many  levels  of  the  study  are  carried  out. 

2.3  Refutation 

The  elements  of  the  third  group  of  FMs  take  an  entirely  different  approach,  that  of  refutation  rather  than  verification 
[24],  that  is,  instead  of  trying  to  prove  that  the  SWICBS  meets  its  requirements,  one  tries  to  refute  the  claim  that  it  does.  The 
advantage  is  that  the  correctness  claim  can  be  refuted  by  one  counter  example,  while  a  proof  must  consider  all  possible  cases. 
There  are  two  kinds  of  refutation.  One  kind  are  those  based  on  computable  properties  of  some  specification  of  the  SWICBS. 
The  second  kind  are  those  based  on  execution  of  some  specification  of  the  SWICBS  on  test  data.  Note  that  neither  of  these 
can  be  verification  of  correctness;  correctness  is  not  a  computable  property,  and  testing  can  be  used  to  show  the  presence  of 
errors,  never  their  absence  [II]. 

Given  a  specification  of  the  complete  SWICBS,  as  in  Level  1  of  the  verification  group  of  FMs,  two  examples  of  comput¬ 
able  properties  that  can  be  used  to  refute  the  claim  of  correctness  are: 

•  type  checking  in  the  specification 

•  cross  reference  checking  in  the  specification 

A  type  error,  undefined  identifier,  or  defined,  but  unused  identifier  can  be  the  symptom  of  a  more  serious  error,  which  a 
thinking  human  being  should  be  able  to  spot  given  the  evidence. 

Given  a  specification  of  the  complete  SWICBS,  as  in  Level  1  of  the  verification  group  of  FMs,  if  the  language  of  the 
specification  is  executable,  e.g.  OBJ  [16]  or  INATEST  [20, 12]  one  should  be  able  to  execute  the  specification  either  with 
actual  data  or  symbolically.  The  execution  with  test  data  may  show  errors  in  the  specified  SWICBS.  Alternatively,  one  might 
be  able  to  build  a  finite  state  model  of  the  SWICBS,  either  directly  or  by  simplifying  the  model  or  abstracting  away  some  of 
the  complexity.  Execution  of  the  finite  state  model  with  test  data  can  show  errors.  In  addition,  if  the  model  is  finite  state, 
there  are  computable  checks,  e.g.,  reachability  analysis,  that  can  be  used  to  show  the  presence  of  problems.  This  group  of 
activities  is  called  model  checking. 

While  locating  an  error  by  refutation  is  not  guaranteed,  in  practice,  model  checking  does  expose  errors,  just  as  does  exe¬ 
cution  of  the  finished  SWICBS.  However,  as  is  shown  in  Section  5,  it  is  highly  preferable  for  an  error  to  be  exposed  early  in 
the  life  cycle  than  later  after  deployment  of  the  finished  SWICBS. ' 

The  refutation  approaches  cost  that  of  Levels  1  and  7  of  the  verification  group  plus  only  5-50%  for  the  refutation,  That 
is,  refutation  drives  the  cost  of  development  up  to  between  2.05  and  2.50  fold,  and  this  is  cheaper  than  with  full  verification. 
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2.4  Programming  Itself  as  an  FM 

preckeTemMUw  just^ik^^in^ct.^even^ore  so^ha^^wWclnpm^ehf/311^113^6  *"  language  with 

prove  the  consistency  of  specifications  and  code  if  code  were  not  fbnw^TlieLf^  S°me  Undefined’  0ne  cou'd  not 
that  writing  a  formal  specification  is  an  FM  Remember  *.*  '  Th.erefore-  Programming  itself  is  an  FM  in  the  sense 

-«*  *»  *■  p— z 

2.5  General  Limitation  of  FMs 

racy  of  thisTSa^mTit^oef  *3^  hTTir™  °f  SWICBS  Under  desi^  » the  accu- 

™nsisM„t  state.  The  specification  couid  fai,  ,o  deal  „ith  2  £ ^ £SK Z 

2.6  Economic  Realities  of  FMs 

for  upm' f  *-  -P«e  quality  by  inspection  [,3, 

for  highly  safety,  and  security.  J,J  systoms  for  which ”hf  os,  o^Sr^l  n^'  T°  ^ 

necessary  to  achieve  the  required  correctness  and  are  well  worth  the  cost  considered  very  high,  FMs  are 

rrr 1  “:s  — * —  si» — **- 

specification  cannot  he  analya  d  *  d'lemma'  Wi'h°“  *N>Hfioation,  the 

problems,  especially  as  abstraction  is  u  fe  d  ,  o  coUansT.  ?  ^  H°W'Ver>  simPliBc*ti^  might  hide  critical 

Pr°  O^rh  ’  d'  r  °Verl00ted  by  “  °f  “a'ysiS  «  »"«  °vel°oh«d  £  Itap'litaion”  °f 

ever  showing  up  laTer  to  2  deX^  ofte  SWCBS  “  n“S  f  °'  ‘  e"°“Sh  *■» 

development  is  reduced  enough  that  Stem  aUoaof an  m ’  !£St n *  2  ^  Kp"'S,V'  “  fix' that  cost  °f  *»  !•» 
unassisted  development  [18  19J  S fsectton ^fiT  mo^  ^  <i«velopm«n,  ts  no  more  or  even  less  Ulan  than  U»,  of  an 

men,  stage  in  which  they  Ire  found  "  ^  mf0rmMm  abOU,  cost  “  «*  ««  «  a  tacUon  of  the  deveiop- 

3  MOST  ERRORS  INTRODUCED  DURING  REQUIREMENTS  SPECIFICATION 

discovery,  spLifica^n^dd^^SST  sm^to requirements 
about  25%  of  the  errors  ever  introduced  into  a  SWICBS  rfil  Striiw t  ,f  d  85%‘  ^  codlng  stage  introduces  only 

the  most  expensive  FM.  Therefore,  lSri225SS  cl  Scales  iS'S  tT  *°  h  ** 

mg  coding,  and  these  errors  are  Drobahlv  rbp  tn  r,  .  •  •  1S  “  0n  y  25 %  of  the  errors  are  introduced  dur- 

inspections  than  to  spend  more  than  10  fold  to  fix  errorc  i  ®eem^ 1  at  lt  ,s  ^ore  cost  effective  to  spend  just  15%  more  for 
requirements.  W  l°  fiX  lntr°duCed  dunng  coding-  Therefore,  the  focus  of  FMs  must  be  on 

4  NO  SILVER  BULLET  (NSB) 

will  dKP“‘,  u  sofl»a« ^^davelopment,  -fhem-s  no  silver  bullet”  [8]  tha, 

into  two  groups,  the  essence fundamenf’ly®as,er  il  has  been.  He  classifies  software  difficulties 


really  awkward  assembly  language  eliminated  by  high-level  languages, 

severe  time  and  space  constraints  eliminated  by  the  introduction  of  big’and  fast  computers 

long  batch  turnaround  time  eliminated  by  time-sharing  operating  systems  and  personal  computers 
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•  tedious  clerical  tasks  for  which  tools  are  helpful  eliminated  by  those  tools,  such  as  make,  res,  xref,  spell,  grep,  fmt,  and 

•  the  drudgery  of  programming  user  interfaces  eliminated  by  tools  for  building  graphic  interfaces  such  as  X  Windows, 

Java,  Visual  Basic  and  other  GUI  libraries. 

These  have  been  significant  advances,  and  they  have  made  coding  significantly  easier  and  less  error  prone.  However,  again, 
these  advances  attack  only  the  minority  of  errors  introduced  by  coding  and  do  nothing  about  the  essence. 

Unfortunately,  the  essence  has  resisted  attack.  We  have  the  same  sense  of  being  overwhelmed  by  the  immensity  of  the 
problem  and  the  seemingly  endless  details  to  take  care  of,  and  we  produce  the  same  kind  of  brain-damaged  SWICBSs  that 
makes  the  same  stupid  kind  of  mistakes,  as  we  did  30  years  ago!  The  source  of  these  errors  is  that  we  just  did  not  understand 
the  conceptual  construct  that  was  to  be  constructed.  We  overlooked  details  or  have  some  details  wrong. 

5  FMs  AND  THE  ESSENCE  OF  SOFTWARE 

Another  way  to  describe  the  essence  is  “requirements”,  not  specifications,  which  are  just  a  statement  of  requirements, 
but  the  requirements  themselves.  FMs  just  do  not  help  identify  requirements.  They  do  not  help  us  crack  the  essence. 

There  is  a  myth  going  around.  Some  FM  evangelists  claim,  “If  only  you  had  written  a  formal  specification  of  the  system, 
you  wouldn’t  be  having  these  problems.  Mathematical  precision  in  the  derivation  of  software  eliminates  imprecision.”  Yes, 
formal  specifications  are  extremely  useful  in  identifying  inconsistencies  in  requirements  specifications,  especially  if  one  car¬ 
ries  out  some  minimal  proofs  of  consistency  and  constraint  or  invariant  preservation.  Interestingly,  writing  a  program  imple-* 
menting  the  specification  also  helps  identify  inconsistencies  in  the  specification;  programming  is  another  FM. 

Contrary  to  the  claim  of  these  evangelists,  FMs  do  not  find  all  gaps  in  understanding.  As  Gordon  and  Bieman  observe, 
omissions  of  functions  are  difficult  to  recognize  in  formal  specifications  [17],  just  as  they  are  in  programs,  von  Neumann  and 
Morgenstem  [25]  say,  “There’s  no  point  to  using  exact  methods  where  there’s  no  clarity  in  the  concepts  and  issues  to  which 
they  are  to  be  applied  ” 

Indeed,  Oded  Sudarsky,  in  a  private  discussion  over  coffee,  pointed  out  the  phenomenon  of  preservation  of  difficulty. 
Specifically,  difficulties  caused  by  lack  of  understanding  of  the  real  world  situation  are  not  eliminated  by  use  of  FMs;  instead 
the  misunderstanding  gets  formalized  into  the  specifications,  and  may  even  be  harder  to  recognize  simply  because  formal 
definitions  are  harder  to  read  by  the  clients.  Sudarsky  adds  that  formal  specification  methods  just  shift  the  lack  of  understand¬ 
ing  from  the  implementation  phase  to  the  specification  phase.  The  air-bubble-under-wallpaper  metaphor  applies  here;  you 
press  on  the  bubble  in  one  place,  and  it  pops  up  somewhere  else. 

FMs  do  have  one  positive  effect,  and  it  is  a  big  one.  Use  of  them  increases  the  correctness  of  the  specifications.  There¬ 
fore,  you  find  more  errors  of  commission  at  specification  time  than  without  them,  saving  considerable  money  for  each  bug 
found  earlier  rather  than  later.  Remember,  the  cost  to  repair  an  error  goes  up  dramatically  as  the  project  moves  towards  com¬ 
pletion  and  beyond.  Figure  1  shows  a  graph  relating  the  relative  cost  to  repair  an  error  as  a  function  of  the  SWICBS  develop¬ 
ment  stage  in  which  the  error  is  found.  Note  that  the  cost  scale  on  the  y-axis  is  logarithmic,  and  the  graph  itself  looks 
exponential  even  on  a  logarithmic  scale.  It  saves  lots  of  money  to  find  errors  earlier,  and  FMs  help  find  errors  earlier.  How¬ 
ever,  these  errors  are  of  commission  rather  than  of  omission 

Another  reason  FMs  do  not  help  identify  requirements  very  well  is  that  requirements  always  change — it  is  inherent  in 
the  software — and  formalization  requires  freezing  the  requirements  long  enough  to  write  the  specification  and  carry  out  the 
verifications.  Meir  Lehman  identifies  concept  of  E-type  system  [21].  It  is  a  system  that  solves  a  problem  or  implements  an 
application  in  some  real  world  domain.  Once  installed,  an  E-type  system  becomes  inextricably  part  of  the  application 
domain,  so  that  it  ends  up  altering  its  own  requirements.  As  an  example,  consider  a  bank  that  exercises  an  option  to  automate- 
its  process  and  then  discovers  that  it  can  handle  more  customers.  It  advertises  and  gets  new  customers,  easily  handled  by  the 
new  system  but  beyond  the  capacity  of  the  manual  way.  The  bank  cannot  back  out  of  automation.  The  requirements  of  the 
system  have  changed  from  being  just  optional  to  being  required.  Also,  daily  use  of  a  system  causes  an  irresistible  ambition  to 
improve  it  as  users  begin  to  suggest  improvements.  Who  is  not  familiar  with  this  phenomenon,  either  as  a  customer  or  as  a 
developer?  In  fact,  data  show  that  most  maintenance  is  not  corrective,  but  for  dealing  with  E-type  pressures!  See  Figure  2. 
Formalization  of  the  requirements  does  nothing  to  make  the  details  of  these  kinds  of  changes  more  predictable. 

6  SECOND  TIME  PHENOMENON 

In  1985, 1  published  a  paper  with  Jeannette  Wing  that  suggests  that  FMs  work,  not  because  of  any  inherent  property  of 
FMs  as  opposed  to  just  plain  programming,  which  is  really  also  an  FM,  but  rather,  because  of  the  second  time  phenomenon 
[2].  If  you  do  anything  a  second  time  around  you  do  better,  because  you  have  learned  from  your  mistakes  the  first  time 
around.  Indeed,  Fred  Brooks  says:  “ Plan  to  throw  one  [the  first  one]  away;  you  will  anyway!”  [7]  In  other  words,  you  cannot 
get  it  right  until  the  second  time.  If  you  write  a  formal  specification  and  then  you  write  code,  you’ve  done  the  problem 
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beca^^^^eawd^mris  nol^tf^™30'*  iS  Irequirements  centered-  0ne  is  «*  going  to  fix  implementation  errors  this  way, 
errors  in  the  rewrite  Thlf  fTTP  35  the  first  time.  Even  if  they  were  the  same,  one  can  introduce  new 
requirement  ereorl  Th  f  f  J"  sPeafication  or  codinS  effort  is  on  understanding  the  essence  and  eliminating 
thoughts  are  always  wiser”°CUS  *  “  °n  lmP,ementinS  the  understood  essence.  As  Euripedes  says,  "Second 


7  THE  IMPORTANCE  OF  IGNORANCE 


ZZt^de'  “Impott.a“e  °”f’orance  in  Requirements  Engineering"  [4J,  I  report  on  my  and  Oma  Bern’s  experi- 

‘i1  ta  rsineerins-  1  obse™d  •>“ 1  »  *>  best  when  7am  into 

fora  E^S  d  Tn-  a  'ZT  '  .  5“"  in  “  a  c0"s“"“t »  help  a  SM-up  write  requirements 

S ro^taHn  n,"S  Pr°Td.  ,hi“  Vf 5W  ““"S  abou*  n“worki"8  a"d  Rfoeme*  beyond  nearly 

S  T  l  •,er,m  mt  fe’ 1  had  worried  *a‘ the  ether  “  Ribemet  cables  might  eva- 

porate.  Despite  my  ignorance,  I  did  a  superb  job,  m  fact,  better  than  I  normally  do  in  my  areas  of  exoertise  Bv  being 

1  r?  abIe  t0  aV°i?/alIing  int0  the  tacit  ^  ^  experience  seemsto  confirm 

the  importance  of  the  ignorance  that  ignorance  hiding  is  so  good  at  hiding.  It  was  clear  to  me  that  the  main  problems 
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preventing  the  engineers  at  the  start-up  from  coming  together  to  write  a  requirements  document  were  that  all  were  using  the 
same  vocabulary  in  slightly  different  ways,  none  was  aware  of  any  other’s  tacit  assumptions,  and  each  was  wallowing  deep 
in  his  own  pit.  My  lack  of  assumptions  forced  me  to  ferret  out  these  assumptions  and  to  regard  the  ever  so  slight  differences 
in  the  uses  of  some  terms  as  inconsistencies. 

My  conclusion  is  that  every  requirements  engineering  team  requires  a  person  who  is  ignorant  in  the  application  domain, 
the  ignoramus  of  the  team,  who  is  not  afraid  to  ask  questions  that  show  his  or  her  ignorance,  and  who  will  ask  questions 
about  anything  that  is  not  entirely  clear.  It  is  not  claimed  that  expertise  is  not  needed.  On  the  contrary,  experts  are  needed  to 
provide  the  material  in  which  to  find  inconsistencies.  Also,  there  is  a  difference  between  ignorance  and  stupidity;  the 
ignoramus  cannot  be  stupid.  On  the  contrary,  he  or  she  must  be  an  expert  in  general  software  system  structures  and  how 
computer-based  systems  are  built.  He  or  she  must  be  smart  enough  to  catch  inconsistencies  in  statements  made  by  experts  in 
fields  other  than  his  or  her  own,  inconsistencies  in  their  tacit  assumptions,  to  abstract  well,  and  to  get  to  the  bottom  of  things. 
Most  importantly,  he  or  she  must  be  unafraid  to  ask  so-called  stupid  questions  to  expose  all  tacit  assumptions.  (This  is  part  of 
smartness  since  usually  stupid  people  are  afraid  to  ask  stupid  questions  for  fear  of  exposing  their  stupidity.) 

The  final  recommendation  is  that  each  requirements  engineering  team  needs  at  least  one  domain  expert,  usually  supplied 
by  the  customer  and  at  least  one  smart  ignoramus. 

As  a  consequence  of  these  observations,  resumes  of  future  software  engineers  will  have  a  section  proudly  listing  all 
areas  of  ignorance.  This  is  the  only  section  of  the  resume  that  shrinks  over  time.  The  software  engineer  wiil  charge  fees 
according  to  the  degree  of  ignorance:  the  more  ignorance,  the  higher  the  fee! 

Soon  after  publication  of  the  Importance  of  Ignorance  paper,  I  received  an  e-mail  letter  from  Martin  Feather.  He  wrote, 

I  have  often  wondered  about  the  success  stories  of  applications  of  formal  methods.  Should  these  successes  be 
attributed  to  the  formal  methods  themselves,  or  rather  to  the  intelligence  and  capabilities  of  the  proponents  of 
those  methods?  Typically,  proponents  of  any  not-yet-popularised  approach  must  be  skilled  practitioners  and 
evangelists  to  [help  bring  the  approach]  ...  to  our  attention.  Formal  methods  proponents  seem  to  have  the  addi¬ 
tional  characteristic  of  being  particularly  adept  at  getting  to  the  heart  of  any  problem,  abstracting  from  extrane¬ 
ous  details,  carefully  organizing  their  whole  approach  to  problem  solving,  etc.  Surely,  the  involvement  of  such 
people  would  be  beneficial  to  almost  any  project,  whether  or  not  they  applied  “formal  methods." 

Daniel  Berry’s  contribution  to  the  February  1995  Controversy  Comer,  ‘The  Importance  of  Ignorance  in 
Requirements  Engineering,”  provides  further  explanation  as  to  why  this  might  be  so.  In  that  column,  Berry 
expounded  upon  the  beneficial  effects  of  involving  a  “smart  ignoramus”  in  the  process  of  requirements 
engineering.  Berry  argued  that  the  “ignoramus”  aspect  (ignorance  of  the  problem  domain)  was  advantageous 
because  it  tended  to  lead  to  the  elicitation  of  tacit  assumptions.  He  also  recommended  that  “smart”  comprise  (at 
least)  “information  hiding,  and  strong  typing  ...  attuned  to  spotting  inconsistencies  ...  a  good  memory  ...  a  good 
sense  of  language...,”  so  as  to  be  able  to  effectively  conduct  the  requirements  process. 

Formal  methods  people  are  usually  mathematically  inclined.  They  have,  presumably,  spent  a  good  deal  of 
time  studying  mathematics.  This  ensures  they  meet  both  of  Berry’s  criteria.  Mastery  of  a  non-trivial  amount  of 
mathematics  ensures  their  capacity  and  willingness  to  deal  with  abstractions,  reason  in  a  rigorous  manner,  etc., 
in  other  words  to  meet  many  of  the  characteristics  of  Berry’s  “smartness”  criterium.  Further,  during  the  time 
they  spent  studying  mathematics,  they  were  avoiding  learning  about  non-mathematics  problem  domains,  hence 
they  are  likely  to  also  belong  in  Berry’s  “ignoramus”  category.  Thus  a  background  in  formal  methods  serves  as 
a  strong  filter,  letting  through  only  those  who  would  be  an  asset  to  requirements  engineering. 

8  THE  LAST  LAUGH  OF  NATURE 

Don  Gause  [15]  points  out  that  there  are  two  kinds  of  people  involved  in  the  development  of  any  SWICBS,  developers 
and  customers.  Each  person  divides  the  universe  of  discourse  (UoD),  the  domain  of  the  SWICBS,  into  two  parts,  what  he  or 
she  knows  (K)  and  what  he  or  she  does  not  know  (DK).  The  effect  of  these  orthogonal  partitions  of  knowledge  divides  the 
UoD  into  four  parts  as  is  shown  in  Figure  3.  The  problem  is  that  we  do  not  know  the  size  of  the  DKs.  We  like  to  think  that 
after  studying  the  problem  a  long  time  and,  the  DKs  have  been  reduced  to  a  tiny  fraction  of  the  Ks.  However,  the  DKs  could 
be  bigger  than  the  Ks  like  the  proverbial  tip  of  the  iceberg.  Even  if,  in  fact,  the  DKs  are  small  compared  to  the  Ks,  the  DKs 
can  never  be  eliminated.  The  parts  of  the  DKs  that  cannot  be  eliminated  are  called  “nature’s  last  laugh”  by  Don  Gause. 
Examples  of  nature’s  last  laugh  include  cold  fusion,  and  all  previously  accepted  but  now  discredited  theories  of  the  universe. 
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The  importance  of  the  ignoramus  comes  through  loud  and  clear.  Everv  RE  team  rennirpc  ,  cm,,*  ,  . 

the  real  world  domain  of  the  system  under  design,  who  is  not  afraid  to  ask  questions  to  reduce  his  or  her  DK  hfan  t0 

get  his  or  her  K  to  include  the  client’s  and  users’  K.  He  or  she  must  not  be  smpid;  in  boZ  ff  * 

system  architecture  to  be  able  to  formulate  enough  of  a  model  to  prompt  the  questions  °  °U 

“?  ‘f  r°‘!  °!  FMS’  “  incteaM  Ks’  b”‘ thM  is  ali  «  can  be.  I,  must  be  accepted  to  toe  will  always  be 
the  DK,  nature  s  last  laugh  to  no  one  will  find  unless  someone  is  lucky  enough  to  ask  the  right  dumb  question.  Y 

9  ANOTHER  EXPERIENCE 

staoet  in  ^se  proceedings  by  David  Robertson  [23],  considers  how  attempts  to  use  FMs  in  the  early 

!-;  ,!  eSMfBS  d  g  fai  •  He  descnbes  his  experiences  trying  to  teach  applied  mathematicians  to  apply  temporal 
3  reaCtlVe  SyStem‘  The  experience  is  m0re  evidence  of  the  importance  of  ignorance  in  writing 

temooraMna'ir  rh^  ^  C°llaboradng  Lfor  the  first  time  with  a  group  of  computer-using  applied  mathematicians  that  knew 
temporal  logic  theory  inside  and  out,  but  had  never  applied  this  theory  to  specify  any  system.  They  were  asked  to  specify  in 

temporal  logic  a  domain  that  practically  invited  temporal  specification.  As  Robertson  described  it  in  e-mail  to  me  irVasan 
obvious  application  which  could  be  done  m  a  short  time  using  simple  temporal  relations  and  forms  of  inference  which  were 

mathematidLrT^pV0  ^  ??  Wh,Ch  the  temporal  ,ogic  gr0UP  is  familiar.”  After  an  initial  failure  to  specify,  the 
nmcrram  In  i  S°mC  embarrassment>  to  write  a  prototype  for  them.  He  rapidly  turned  out  a  Prolog 

pr  gram,  of  less  than  100  lines  of  the  kind  that  a  bright  second  year  undergraduate  should  be  able  to  write.  This  prototype 

pr°Vsed  be  enough  of  a  tngger>  and  the  mathematicians  are  now  happily  turning  out  specifications  of  more  complex  sys- 

.  2e#/SthSnadCia,l?  STPly  C°Uld  n0t  takC  the  firSt  Step  w5thout  s°mething  concrete  to  help  them.  Robertson  believes 
he  theo^heUv  LWaSt  l,67  uGd  tra!ning  in  Pr°blem  rePresentation-  As  happens  with  students  who  are  unable  to  apply 
nfVro!7,  h?  i  pr<?blenlS’ the  mathematicians  had  not  developed  any  intuition  about  how  to  abstract  away  the  details 

of  h  2  ?  Pry  'em’"  °rdeIf t0  get  3  USefuI  sPecification-  Robertson  believes  that  “it  is  often  easier  to  produce  the  sort 
of  idealised  system  I  described  above  if  you  are  ‘just  ignorant  enough’  about  logic  not  to  be  drawn  into  too  complex  model- 

_L“, 3y  S*age  but  Just  smart  enough’  not  to  make  logical  goofs  and  to  be  able  to  transfer  the  initial  prototype  to  more 
experienced  hands.  People  m  this  line  of  work  need  to  retain  a  certain  amount  of  wide-eyed  ignorance  of  the  domain  -  oth¬ 
erwise  they  would  be  tempted  to  model  problems  too  deeply,  which  is  fun  but  seldom  profitable.” 

10  SOCIAL  PROCESSES  AND  FMs 

It  is  also  my  belief  that  the  proper  context  for  FMs  in  the  development  of  SWICBS  is  in  the  highly  social  process  of 
requirements  eng, neenng.  This  recalls  the  1979  DeMillo,  Lipton,  and  Perlis  paper,  “Social  Processes  and  Proofs  of 
Theorems  and  Programs  [10].  They  observed  that  mathematical  proofs  work  because  of  the  social  processes  in  and  around 
em  that  help  to  insure  that  only  correct  theorems  get  published  (and  even  then  they  are  not  all  correct).  They  argued  that  the 
proofs  required  by  FMs  applied  to  programming  are  generally  carried  out  by  grunt  mathematicians  working  alone  and 
wit  out  t  e  ene  t  of  social  interaction,  because,  unlike  publishable  proofs  in  mathematics,  proofs  about  programs  are  quite 
simply  and  frankly  boring.  Bored  grunt  mathematicians  make  mistakes.  Proofs  without  social  processes  are  not  trustworthy 
enough  for  the  needs  of  systems  critical  enough  to  justify  the  cost  of  FMs. 


11  CONCLUSIONS 

It  is  my  belief  that  FMs  work  when  they  work,  not  so  much  because  of  formality,  but  rather  because  of 
1 .  what  is  learned  when  applying  FMs,  that  can  be  applied  in  the  next  round  of  development  and 
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2.  the  nature  of  the  people  who  willingly  and  enthusiastically  apply  FMs. 

Despite  the  weakness  of  FMs  at  discovering  new  requirements,  FMs  work  best  when  they  are  being  applied  to  the  RE  stage 
of  SWICBS  development  to  help  understand  and  correct  the  requirements. 
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Abstract 

We  explore  the  role  of  lightweight  inference  techniques  in  creating  highly  automated  engineering 
support  environments  for  the  development  of  computer-based  systems.  Lightweight  inference  techniques 
are  scalable  methods  for  automated  reasoning.  We  outline  the  types  of  automation  that  would  be 
enabled  by  effective  lightweight  inference  capabilities  and  survey  some  promising  approaches  to  realizing 
the  needed  capabilities. 


1  Introduction 

We  need  improved  capabilities  for  constructing  computer-based  systems,  particularly  regarding  reliability, 
cost,  development  delay,  and  responsiveness  to  change.  These  needs  can  be  addressed  by  automating  some 
of  the  design  and  development  work  currently  done  by  engineers.  This  includes  analysis,  synthesis,  and 
transformation  tasks  that  require  reasoning  support  [12,  8].  This  paper  explores  the  types  of  inference 
needed  in  this  context,  and  identifies  some  key  issues  for  progress. 

According  to  another  paper  in  this  proceedings  [2],  use  of  formal  methods  costs  2-10  times  more  than 
just  producing  code.  That  analysis  assumes  conventional  processes  where  software  systems  are  developed 
one  at  a  time  by  economically  separate  projects.  In  that  context,  the  analysis  suggests  that  formal  methods 
are  economically  justified  only  for  products  where  the  cost  of  software  failure  is  very  high.  This  picture  is 
not  very  promising  for  cost-effective  production  of  high  quality  software. 

An  alternative  path  to  cost-effective  quality  software  is  to  amortize  formal  methods  effort  over  develop¬ 
ment  of  many  systems.  For  greatest  benefit  of  this  strategy,  we  need  reliable  generators  that  can  produce 
reliable  software  for  many  related  applications.  This  reuses  parts  of  the  formal  methods  effort  spent  on 
the  critical  requirements  determination  aspect  [20]  as  well  as  on  conceptual  modeling,  software  architecture, 
and  verification  of  the  program  generation  patterns  to  realize  the  architecture.  The  systems  created  by  a 
generator  can  be  different  products  in  the  same  application  domain,  or  they  can  be  improved  releases  of  the 
same  product.  The  latter  pattern  is  economically  significant  because  the  bulk  of  software  cost  is  attributable 
to  software  evolution  rather  than  to  development  of  new  systems. 

A  key  benefit  of  the  reliable  generator  approach  is  systematic  and  non-decreasing  improvement  in  soft¬ 
ware  quality,  both  in  the  requirements  aspect  and  in  the  correctness  of  code  with  respect  to  requirements. 
The  approach  addresses  requirements  by  reusing  domain  knowledge  and  corrective  feedback  from  prior  appli¬ 
cations  [11].  It  reduces  the  particularly  problematic  errors  of  omission  because  requirements  issues  identified 
in  previous  applications  of  the  domain  can  be  systematically  checked.  It  enables  monotonic  improvement  of 
program  reliability,  because  once  a  bug  in  a  program  generation  pattern  is  fixed,  it  stays  fixed  for  all  future 
applications  of  the  pattern.  As  a  limiting  case,  if  the  patterns  can  be  proven  correct,  then  all  future  applica¬ 
tions  generated  by  the  patterns  will  also  be  correct,  without  need  for  any  further  proofs  unless  new  rules  are 
added.  Automatic  generation  of  the  application  programs  is  necessary  for  success,  to  prevent  human  error 
in  the  application  of  the  certified  program  generation  rules.  Automatic  tools  at  the  requirements  level  are 
needed  for  the  same  reason. 

Lightweight  inference  addresses  issues  on  the  critical  path  to  this  vision.  Automatic  inference  is  needed 
to  realize  many  parts  of  the  automatic  tools.  For  example,  inference  is  needed  to  check  the  applicability 

•This  research  was  supported  in  part  by  U.  S.  Army  Research  Office  under  contract/grant  number  38690  and  in  part  by  the 
the  Army  Research  Lab  under  grant  number  7DNAVYR010. 
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conditions  associated  with  each  program  generation  rule,  to  determine  which  rules  are  applicable  to  a  par¬ 
ticular  problem  instance,  and  to  decide  which  is  most  beneficial  if  more  than  one  generation  rule  apphes 
Inference  capabilities  are  also  needed  in  engineering  automation  for  synthesizing,  transforming,  and  checking 
the  program  generation  rules,  architectures,  and  requirements  models.  S 

StUdid  f0r.mtny  yeatS  in  the  COntext  0f  Philos°Phy.  logic,  and  mathematics.  This 
work  has  addressed  many  theoretical  issues  such  as  soundness,  completeness,  and  decidability  of  various 

inference  SySt6mS'  TheS6  feSultS  have  contributed  a  ^  deal  to  our  general  understanding  of  logic  and 

Some  of  these  general  issues,  such  as  soundness,  are  relevant  to  our  goals.  An  inference  system  is  sound 
if  only  valid  statements  can  be  proved.1  Soundness  is  essential  for  engineering  inference.  Automated  design 
processes  must  give  dependable  results  before  engineers  will  stake  their  reputations  on  them. 

However,  other  issues  emphasized  in  mathematical  logic  differ  from  those  most  relevant  to  engineering 
automation.  °  6 


1.1  Inference  in  Mathematics 

Formal  systems  for  inference  are  part  of  the  foundations  of  mathematics,  and  have  been  studied  extensively 
m  the  context  of  mathematical  logic.  Logicians  are  interested  in  deductive  power,  and  have  established 
widely  accepted  criteria  such  as  completeness  and  decidability. 

An  inference  system  is  complete  if  every  valid  statement  has  a  proof.  In  logic,  completeness  of  an  inference 
system  is  a  commonly  accepted  indication  of  optimal  deductive  power:  it  says  every  true  statement  has  a 
proof.  In  the  abstract  completeness  is  an  attractive  goal.  Note  that  completeness  is  concerned  with  existence 
of  a  proof,  rather  than  whether  there  is  a  way  to  check  if  a  proof  exists  or  how  long  the  proof  might  be 
A  logic  is  decidable  if  there  exists  a  procedure  that  will  determine  whether  any  well  formed  statement 
of  the  logic  is  true  or  false  in  a  finite  number  of  steps.  Any  question  that  can  be  formulated  in  a  decidable 
logic  can  in  theory  be  answered  by  an  automated  process.  This  criterion  is  also  an  idealization,  because  it 
accepts  any  procedure  that  is  guaranteed  to  terminate  for  all  inputs,  regardless  of  how  many  steps  it  may 

take.  Decidability  would  be  a  practical  criterion  of  deductive  power  in  a  world  where  clients  have  infinite 
lifetimes. 


1.2  Inference  for  Engineering  Automation 

Inference  supporting  engineering  automation  for  computer  based  systems  must  face  practical  concerns. 

Most  logics  useful  for  software  modeling  are  not  decidable.  For  example,  first  order  predicate  calculus 
becomes  undecidable  if  augmented  with  standard  interpretations  for  data  types  that  commonly  appear  in 
software,  such  as  integers  or  lists.  It  is  therefore  difficult  to  address  our  subject  matter  within  the  confines 
of  known  decidable  systems. 

Since  engineering  applications  demand  soundness  and  inference  systems  that  are  both  sound  and  com¬ 
plete  do  not  exist  for  undecidable  logics,2  incomplete  inference  systems  are  highly  relevant  for  engineering 
automation. 

Even  for  engineering  problems  that  can  be  expressed  in  a  decidable  logic,  we  must  face  the  issue  that 
decision  procedures  typically  have  at  least  exponential  running  times,  even  for  the  simplest  and  weakest 
logics.  Software  analysis  and  synthesis  problems  encountered  in  practice  are  large,  typically  millions  rather 
than  tens  of  lines  of  code.  Practical  efficiency  constraints  rule  out  exponential  algorithms  at  this  scale,  unless 
we  can  partition  large  practical  problems  into  independent  parts  with  (small)  constant  bounds  on  the  size 
of  the  largest  indivisible  subproblem. 

Most  software  analysis  problems  are  not  decidable  if  we  insist  on  perfect  solutions  for  all  possible  pro¬ 
grams.  Fortunately,  we  only  have  to  solve  the  problems  that  occur  in  engineering  practice,  not  all  problems 
expressible  in  common  logic  or  programming  languages.  There  has  been  little  success  in  inventing  languages 

‘Valid  means  true  for  all  possible  models,  i.e.  for  all  possible  interpretations  of  the  symbols  in  the  statement  that  do  not 
have  predefined  meanings  in  the  logic. 

2  A  decision  procedure  for  the  closed  sentences  of  a  two-valued  logic  with  a  sound  and  complete  inference  system  can  be 
obtained  by  enumerating  all  theorems  until  either  the  closed  sentence  or  its  negation  appears. 
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that  can  express  the  problems  arising  in  software  engineering  practice  but  do  not  have  the  additional  capa¬ 
bility  to  express  many  intractable  problems  that  do  not  arise  in  practice.  This  puts  a  premium  on  efficiently 
solvable  special  cases  and  safe  approximations  that  cover  the  situations  arising  in  engineering  practice.  For 
example,  compilers  axe  commonly  designed  to  issue  error  messages  for  all  cases  that  cannot  be  efficiently 
certified  to  be  well-formed,  even  if  this  means  excluding  some  inputs  that  are  not  in  fact  errors. 

Thus  inference  for  engineering  automation  of  computer  based  systems  is  subject  to  very  different  con¬ 
straints  than  the  kind  of  inference  that  has  been  studied  in  mathematics  and  logic,  and  has  different  goals 
and  priorities. 

We  use  the  term  lightweight  inference  to  denote  inference  systems  that  can  operate  within  these  con¬ 
straints,  which  require  soundness  and  extremely  high  efficiency  but  tolerate  incompleteness  and  limited 
expressive  power. 

The  rest  of  the  paper  is  organized  as  follows.  Section  2  discusses  the  requirements  for  the  inference 
facilities  needed  to  support  engineering  automation.  Section  3  presents  some  past  successes  in  automated 
inference  and  automated  derivation  on  a  large  scale,  and  examines  the  factors  that  enabled  these  successes. 
Section  4  identifies  some  of  the  most  promising  past  approaches  that  may  grow  into  future  solutions  to  the 
lightweight  inference  problem.  Section  5  contains  conclusions. 


2  Inference  Requirements  for  Engineering  Automation 

This  section  outlines  the  requirements  that  must  be  met  by  automated  methods  for  lightweight  inference. 

1.  The  methods  must  give  reliable  conclusions.  This  is  the  soundness  requirement  identified  above,  which 
is  essential  for  practical  impact. 

2.  The  methods  must  be  effective  on  a  large  scale.  This  is  the  efficiency  requirement,  which  depends  on 
the  context.  The  design  aids  supported  by  lightweight  inference  can  be  separated  into  two  categories, 
immediate  and  background.  Immediate  feedback  is  intended  to  alert  the  designer  to  relevant  design 
issues  or  faults  as  they  are  introduced.  Response  time  is  limited  to  a  few  seconds  for  immediate 
feedback,  because  otherwise  the  designer’s  attention  will  shift  to  different  issues,  and  slow  feedback 
will  interrupt  thought  rather  than  aiding  it.  Background  analysis  tasks  must  take  no  longer  than  an 
overnight  run  to  be  practical.  In  either  case,  the  inference  mechanism  must  be  completely  automatic, 
without  interactive  guidance  from  a  human  user  -  otherwise  the  process  would  be  too  slow  and  too 
expensive  to  be  cost  effective.  The  interaction  paradigm  in  this  case  is  precomputation  of  anticipated 
queries  whose  results  are  displayed  only  when  the  programmer  requests  them.  In  either  case,  the 
efficiency  requirements  are  more  stringent  than  commonly  assumed  in  theoretical  work  on  inference. 

3.  The  methods  must  be  able  to  solve  problems  that  occur  in  practice.  Complete  coverage  is  not  required  for 
practical  usefulness.  Special  purpose  methods  that  are  limited  to  particular  special  cases  are  acceptable 
and  may  be  desirable  if  they  perform  well  on  cases  that  arise  in  practice. 

4.  The  methods  must  be  able  to  perform  inferences  “ obvious ”  to  people.  Due  to  the  extreme  efficiency 
constraints,  we  should  not  expect  lightweight  inference  systems  to  solve  deep  mathematical  problems 
that  puzzle  human  experts.  We  should  expect  these  systems  to  be  able  to  determine  properties  that 
are  obvious  to  professional  engineers.  The  importance  of  automated  inference  is  to  be  able  to  handle 
very  large  numbers  of  such  problems,  at  much  higher  speeds  and  with  much  lower  error  rates  than 
people  could  accomplish.  The  inference  capabilities  should  handle  the  parts  of  the  engineering  process 
that  appear  conceptually  routine  when  considered  in  isolation.  Such  issues  can  be  major  problems 
in  engineering  practice  because  of  sheer  volume  of  detail  and  large  numbers  of  relatively  simple  but 
interacting  constraints. 

5.  The  methods  must  be  able  to  find  solutions ■  in  addition  to  deciding  properties.  Often  engineers 
need  examples  or  counter  examples  in  addition  to  deciding  whether  given  properties  are  true  or  false. 
Sometimes  this  problem  arises  in  the  form  of  determining  particular  values  for  some  parameters  that 
will  make  certain  logical  constraints  true,  sometimes  with  the  additional  goal  of  optimizing  some 
objective  function.  A  related  problem  is  finding  the  weakest  set  of  additional  constraints  that  will 
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suffice  to  satisfy  a  given  goal  statement.  In  the  context  of  software  engineering,  it  is  desirable  to 

o.h«  S  of  taSSaa^With  f0t  Sy”theSi2lnE  Pr0StamS  “  telE"  m 

6.  The  methods  must  be  feasible  for  practicing  engineers  to  learn  and  use.  This  Duts  a  nrpmmm  i 

conceptual  models  of  engineering  processes  and  user  interfaces  that  match  the  thinking  habits  of  typical 
ngmeers  A  successful  strategy  for  simplifying  the  interfaces  has  been  to  encapsulato  the 3S 
Ub f  mathematlcai  concepts  inside  of  tools  [16, 19,  24].  It  is  acceptable  to  require  toolsmiths  to  havl 
eve  s  of  mathematical  skill  that  far  exceed  those  of  typical  software  engineers  using  tools  with  internal 
lightweight  inference  capabilities.  Interface  amenities  such  as  active  documentation,  explanation  and 
guidance  facilities  can  help  but  they  are  no  substitute  for  conceptual  simplification  at  the  interfaces 
and  information  hiding  applied  to  deep  theories  of  computing. 

7  SLm±f  must  have  a  failure  interface  to  handle  incompleteness.  Incomplete  methods  may  fail 
These  cases  must  be  explicitly  reported  as  failures,  so  that  there  is  no  danger  of  basing  delivered 

the  rafi°nf^Ul  ty  COnd,US10ns; , 1x1  such  ca5es<  the  inference  system  should  help  isolate  and  diagnose 
the  causes  of  failures,  and  provide  guidance  about  how  to  mitigate  or  work  around  them.  Such  faflures 

nrnbf en  Iw?*,  ^  °f  part,lcularly  difficult  Parts  of  problem.  If  the  engineers  are  to  solve  the 

anH^nT  ^  aU,t0mated  systems  cannot  handla.  they  will  need  assistance  in  isolating,  simplifying 
and  understanding  them  to  have  much  chance  of  success. 

8'  ill  Fo!wf“?e  r°lU5t  and  Pr£dic!able-  The  methods  should  terminate  gracefully  when  they 
ll. .  For  best  acceptance  by  engineers,  the  cases  in  which  the  methods  are  expected  to  succeed  and 

the  amount  of  time  they  will  require  should  be  predictable.  It  is  best  if  tractable  special  cases  can  be 
automatically  detected  by  the  system,  and  solution  times  estimated  in  advance,  particularly  if  they  are 
long.  Since  efficient  methods  tend  to  involve  large  numbers  of  rules,  this  puts  a  premium  on  computer 
aid  for  analyzing  behavioral  and  performance  properties  of  the  rules. 

9.  The  methods  must  be  adaptable.  Engineering  automation  is  a  complex  problem  domain  that  is  not 
currently  complete  y  understood.  In  particular,  an  important  part  of  the  problem  is  productive  in- 

nr^i  T  WL  vf  UPed  pe°P!e  and  business  organizations.  Prototyping  will  be  necessary  to  test  the 
fw!  fVia?l  y?f  research  ^sults  m  realistic  engineering  contexts,  identify  new  issues  implicit  in 
ose  contexts,  and  improve  automation  support  to  address  those  issues  and  to  provide  gradually  im¬ 
proving  capabilities.  Economic  concerns  also  require  some  early  demonstration  of  some  returns  on 
investment  before  all  aspects  of  the  problem  are  solved.  This  puts  a  premium  on  computer  aid  for 
hanging  and  extending  the  rules  that  drive  lightweight  inference  systems,  and  on  improved  models 
and  representations  for  formulating  and  transforming  the  rules. 

2.1  Some  Automatable  Engineering  Tasks 

Lightweight  inference  needs  to  be  able  to  address  problems  that  occur  in  practice  but  are  not  “too  hard”, 
to  make  this  idea  concrete,  this  section  presents  some  examples  of  software  engineering  subtasks  that  should 

be  completely  automatable  with  the  help  of  lightweight  inference  facilities  and  proper  choice  of  safe  approx- 
imations.  ^ 


1.  Type  inference.  Synthesis  of  type  declarations  in  types  programming  or  specification  languages,  and 
generation  of  diagnostics  in  case  of  type  errors. 

2.  Non-local  references.  Resolving  non-local  references,  synthesizing  Ada  WITH  statements,  and  gener- 
ating  menu  choices  when  there  is  more  than  one  type  consistent  choice. 

3.  Uninitialized  variables.  Detecting  references  to  uninitialized  variables,  and  generating  appropriate 
warning  displays  at  design  entry  time. 

4.  Exception  handlers.  Determining  the  set  of  exceptions  that  can  be  raised  by  each  statement,  and 
synthesizing  default  exception  handlers. 
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5.  Closing  files .  Determining  the  set  of  open  files  and  synthesizing  close  statements  at  the  end  of  the 
appropriate  scope. 

6.  Locks .  Determining  the  set  of  locks  needed  and  synthesizing  statements  to  acquire  and  release  locks 
as  needed. 

7.  Freeing  storage.  Detecting  local  dynamically  allocated  objects  and  synthesizing  storage  recycling  op¬ 
erations  when  safe. 

8.  Slicing.  This  a  a  form  of  dependency  tracing  that  involves  forming  transitive  closures.  Applications 
include  finding  all  program  statements  that  can  affect  the  truth  of  an  invariant,  identifying  unreachable 
code,  factoring  unstructured  descriptions  into  logically  cohesive  modules,  and  many  others. 

9.  Stubs.  Synthesizing  stubs  that  enable  execution,  demonstration,  or  delivery  of  partially  completed 
systems. 

10.  Concrete  interfaces.  Synthesizing  default  concrete  interfaces,  including  graphical  user  interfaces,  from 
abstract  interfaces  (such  as  those  implicit  in  an  object  design  or  an  essential  model  of  the  system). 

11.  Test  scaffolding.  Synthesizing  the  additional  code  needed  to  test  an  implementation  module  according 
to  a  given  testing  approach. 

While  each  of  these  issues  is  in  some  sense  routine,  all  of  them  consume  substantial  engineering  time 
in  practice,  especially  when  error  correction  and  proper  response  to  modifications  of  engineering  artifacts 
(requirements,  specifications,  decompositions,  interfaces,  programs, ...)  are  taken  into  account.  Furthermore, 
each  of  them  involves  fairly  sophisticated  design  and  process  considerations  and  non-trivial  design  decisions 
if  it  is  to  be  resolved  in  a  systematic  way  to  meet  stringent  quality  standards,  in  a  realistic  engineering 
environment  where  complete  coverage  is  needed  and  common  academic  simplifying  assumptions  cannot  be 
used. 

2.2  Some  Partially  Automatable  Engineering  Tasks 

This  section  presents  some  more  difficult  software  engineering  tasks  that  should  be  partially  automatable 
with  the  help  of  lightweight  inference  facilities. 

1.  Timing  analysis .  For  real-time  applications,  it  is  often  necessary  to  get  accurate  upper  bounds  on 
how  much  time  it  will  take  to  execute  a  given  subprogram.  Lightweight  inference  techniques  should 
be  able  to  automatically  determine  the  number  of  microseconds  per  control  block,  and  whether  or  not 
the  recurrence  relations  that  lead  to  bounds  on  the  number  of  loop  iterations  and  the  depths  of  the 
recursions  in  the  subprogram  match  any  of  the  solution  patterns  in  a  database  of  known  solutions. 
Interactive  help  or  heavyweight  inference  support  may  be  needed  to  solve  recurrence  relations  that  do 
not  match  the  patterns  in  the  database. 

2.  Space  analysis.  Embedded  systems  sometimes  need  accurate  bounds  on  the  amount  of  space  needed 
to  execute  a  given  program.  Lightweight  inference  techniques  should  be  able  to  derive  the  number  of 
bits  per  node  or  object.  Interactive  help  may  be  needed  to  get  bounds  on  the  length  of  a  linked  list  or 
the  number  of  instances  of  a  type  used  in  the  program  that  do  not  match  the  patterns  in  a  solution 
database. 

3.  Completing  loops  and  data  structures.  A  mature  engineering  automation  environment  could  include 
decision  support  facilities  that  can  synthesize  statements  to  restore  invariants  after  manually  designed 
code  has  changed  some  loop  variables  or  data  structure  components.  Lightweight  inference  should  be 
able  to  automatically  determine  the  sets  of  affected  variables  and  weakest  preconditions  of  sections 
of  straight  line  code.  Some  interactive  help  may  be  needed  for  synthesizing  the  statements  to  restore 
the  invariants  based  on  this  information  for  cases  that  cannot  be  handled  by  a  database  of  synthesis 
patterns. 
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Reuse  i  ^  S°lutions  that  serves  33  311  online  handbook. 

2.3  Design  Representations  and  Characteristics 

This  section  briefly  characterizes  the  types  of  design  representations  used  in  software  design  to  fi.rtW 
characterize  typical  applications  of  lightweight  inference.  *  ^  4  further 

Software  designs  involve  many-tomany  relations  of  many  kinds.  Graphs  and  hynergraohs  are  rnmmm 

Software  designs  involve  named  objects  with  scope  rules.  Examples  are  variables  design  modules  tvne* 
requirements,  and  so  on.  These  names  can  typically  be  overloaded,  so  that  some  inference  may  be  needed 
to  resolve  them.  Names  typically  have  many  occurrences,  which  introduce  dependencies  of  various  kinds 

materialize  dependencies  expiicitiyi  check  consistency  <— *•  -d  ^ 

Software  designs  are  typically  updated  concurrently  by  teams  of  designers,  working  is  a  distributed 

ST JT7Z  COUW  T"  l°  d“*  °r  “  ->a«oosSbetweenfc 

othef team  memte  “  imPendinS  lnteracUons  wllh  d«“  made  by 


2.4  Common  Types  of  Inferences 

*he  PreVi0US  CharlCterlMti0"S  °f  ■"*-*“  *  **-«* 

.  *n  ®n6ine®rinS  coatexts  U  is  often  necessary  to  check  or  determine  non-local  properties  of  design  ob- 
commonlP  erj  reJatl°nS, mUSt  be  maintained  and  processed,  and  closure  calculations  of  many  kinTs  are 
sTpTram  caUeLSn„bT  d'P?nde“des  “  flow  ^^"dendes.  control  flow  dependencies. 
S  versTons  sf  i  '  T  ?  T’  '"’TT'”*3  dePende“i:i's.  «d  configuration  dependencies  be¬ 

rated  bv  a  d»ln  L„?„  t  °  a  cteure  calculation  is  determining  the  set  of  exceptions  that  can  be 

proper,y  “ whether  *  - » s“bpr^m  -  *  — «• * 

indivichiallv  f°r  nU"?erS  f  i°feieaces  that  are  conceptually  simple  when  considered 

n  nrn™  I  T  6'  pr°partieS  such  33  whether  a  g^en  identifier  denotes  a  predefined  type  arise  often 

hevTv  annl  r3  ’  ft T  !.  °f  depends  0n  Such  Pities.  One  at  a  time, 

ImhW  w  ?lV1f  ’  b  hea  they  COme  by  the  millions  in  a  larSe  scale  application,  they  can  be  a  major 
problem.  We  need  systematic  and  computer-aided  methods  for  handling  issues  like  this  in  many  variations. 

3  Past  Successes  of  Automated  Inference/Derivation 

ittweawJr^rr/f1  am°rnt  °!  *2?. rdevant  to  the  SoaIs  of lightweight  inference,  although  much  of 

is  weakly  related  to  proofs  and  logic.  This  section  briefly  identifies  and  characterizes  some  of  that  work. 

3.1  Some  Examples 

Here  are  some  of  the  contexts  where  simple  inferences  have  been  successfully  automated  on  a  large  scale. 
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1.  Optimizing  compilers.  Compilers  routinely  determine  properties  of  large  programs  to  drive  optimization 
processes  and  check  for  some  kinds  of  semantic  errors. 

2.  Databases.  Queries  on  databases  determine  properties  of  large  data  collections. 

3.  Symbolic  mathematics.  Symbolic  mathematics  systems  solve  large  math  problems,  some  of  which  are 
beyond  the  practical  capabilities  of  unaided  humans. 

4.  Optimization.  Optimization  methods  such  as  linear  and  integer  programming  find  solutions  to  large 
problems.  Another  paper  in  this  proceeding  [15]  gives  an  example  of  this  relevant  to  software  engi¬ 
neering  automation. 

5.  Model  checkers.  Model  checkers  find  problems  in  complex  designs  and  protocols. 

6.  Schedulers.  Real-time  scheduling  algorithms  establish  complex  existence  properties. 

7.  Heuristic  search.  Heuristic  search  methods  find  solutions  in  complex  domains  such  as  games  (chess) 
and  VLSI  design  (routing  and  layout). 

The  first  four  of  these  contexts  are  quite  mature  and  many  commercial  tools  are  available.  Based  on  this 
past  experience,  we  conclude  that  lightweight  inference  should  be  feasible.  However,  the  kinds  of  lightweight 
inference  needed  for  engineering  of  computer  based  systems  have  not  been  intensively  studied,  and  we  believe 
that  substantial  progress  in  this  area  is  possible. 

3.2  Common  Themes 

Several  past  successes  rely  on  domain-specific  inference  and  derivation  procedures.  These  procedures  rely  on 
special  properties  of  the  application  domains  to  achieve  their  efficiency  and  effectiveness.  Expressive  power  is 
commonly  limited  and  tailored  to  the  application  domain.  The  methods  produce  accurate  results  when  they 
succeed,  and  produce  error  messages  when  they  fail.  These  error  messages  approximately  explain  failures, 
and  although  current  facilities  leave  much  to  be  desired  in  this  area,  the  error  messages  often  do  contain 
enough  information  to  enable  skilled  users  to  diagnose  and  correct  the  causes  of  the  failures. 

The  past  successes  also  have  some  common  difficulties.  Foremost  among  these  is  that  the  decision  rules 
are  complex  and  quite  difficult  to  create,  analyze,  certify,  and  extend.  Domain-specific  inference  often 
requires  large  numbers  of  similar  rules.  These  systems  are  generally  not  very  modular,  and  consequently 
they  are  very  difficult  to  extend  and  refine.  In  many  cases  inference  rules  are  implicitly  encoded  in  complex 
algorithms.  Even  if  the  rules  are  explicit,  they  may  not  be  systematically  organized.  Generalization  is  weakly 
supported,  or  not  at  all.  There  is  little  or  no  automated  decision  support  for  creating,  analyzing,  organizing, 
and  improving  the  rules. 

Another  problem  is  that  failure  diagnosis  is  incomplete  and  sometimes  inaccurate.  Most  systems  do  not 
produce  advice  on  what  to  do  to  work  around  failures,  and  some  do  not  even  provide  information  that  could 
help  to  localize  the  cause  of  the  failure. 

3.3  How  Efficiency  was  Achieved 

A  principal  challenge  for  lightweight  inference  is  achieving  adequate  efficiency.  This  section  briefly  examines 
how  past  successes  managed  to  get  enough  efficiency  to  scale  up.  _ 

A  major  theme  has  been  to  avoid  nondeterminism  as  much  as  possible.  Since  the  cost  of  a  search  is 
typically  exponential  in  the  number  of  undetermined  choices,  many  methods  go  to  great  lengths  to  reduce 
or  eliminate  choice  points.  Special  structures  of  the  problem  domain  are  exploited  to  accomplish  this,,  often 
via  dominance  properties,  equivalences,  special  representations  for  entire  classes  of  cases,  and  heuristics  for 

pruning  searches.  , 

Another  theme  is  to  keep  inference  chains  short.  This  leads  to  large  numbers  of  very  specific  rules  and 

algorithms  that  are  coupled  to  the  structure  of  the  problem  space. 

Using  memory  to  avoid  recomputation  and  optimizing  the  frequently  repeated  steps  are  additional  strate¬ 
gies  that  has  been  used  to  improve  efficiency  in  the  past  successes. 
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4  Future  Directions 

rs  sjsss  see*  t* ^  r  ““**  ■*«*■  *»«  ^  be 

relatively  good  efficiency  properties  fnd  thev  ar?’a  T^ese  “ethods  have  been  singled  out  because  they  have 
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4.1  Compiler  Technology 

first  because  it  is  the  most  mature  and  the  most  efficient.  ^  ’  9  '  Th  technoloSy  1S  mentioned 

^Efficie^111  7h6^  4 
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Large  rule  sets  appear  to  be  inherent  in  the  determinism  that  produces  the  efficiency  advantage,  nf  th, 
approach.  Our  desire  for  improved  modularity  and  higher  conceptual  levels  of  suDDort  in  modplinAi,  i 

xzsz?  cutre“i  comp,urs  to  ^  «* 

The  use  of  computed  attributes  to  synthesize  routine  parts  of  desiens  k  at  th.  ti...t  „t  „  i  . 

k  needed  ,0  deve,op  formal  systems  tbat  caa 

constraints  that  are  automatically  enforced  via  synthesis  rules  do  not  always  naturally  fit  into  a  master /slave 
abk  to  n  H  ra  r  Wierre  th,e  ”'CeSSlr)r  acti°"  fa  toermined  to  cither ie  ^  wouTdl  k^to  to 

rs,SZd  a  pendency  chaln  and  have  the  other  end  readi“Kd 

Modrx-r“s 

~ ,deas  to  “  ^ 

4.2  Rewrite  Rules 

Another  well  studied  context  for  automated  inference  is  equational  logic  and  rewrite  rules  [13, 10  6  7] 

The  strengths  of  this  approach  are  its  well  developed  theory,  which  can  in  principle  support  systematic 
analysis  of  rules,  its  type  structure,  and  the  associated  (checkable)  validity  constraints  on  rules  This  tech¬ 
nique  also  has  some  efficiency  benefits,  which  are  somewhat  weaker  than  L  attribute  grammar Ipproat: 
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for  rule  sets  with  the  church-rosser  property,  it  is  possible  to  replace  search  with  deterministic  choice  of 
which  rule  to  apply  at  each  point  without  affecting  the  result. 

The  weaknesses  of  the  approach  are  that  typical  engineers  do  not  understand  how  to  use  it,  it  supports 
only  functional  (single-valued)  attributes,  it  does  not  support  shared  design  objects,  change  propagation  and 
rule  refinement  are  not  supported,  rule  analysis  may  not  be  computable,  links  to  engineering  design  repre¬ 
sentations  are  missing,  and  current  implementations  are  not  efficient  enough  to  handle  very  large  problems. 

Our  experience  with  trying  to  teach  algebra  and  rewrite  rules  to  master’s  students  in  computer  science 
indicates  that  most  of  them  fail  to  understand  the  principles  deeply  enough  to  be  able  to  apply  them  in 
synthesis  and  engineering  design.  We  believe  that  this  population  represents  a  reasonable  upper  bound  on 
the  skill  levels  of  practicing  software  engineers.  This  skill  requirement  is  a  barrier  to  widespread  application, 
which  suggests  that  lightweight  inference  techniques  based  on  this  approach  must  hide  the  algebra  inside  a 
tool  that  provides  simpler  design  representations  to  its  users. 

4.3  Resolution 

Another  well  known  approach  to  inference  is  Horn  clause  logic  and  resolution  [23,  21]. 

The  strengths  of  the  approach  are  its  well  developed  theory,  which  can  also  in  principle  support  analysis 
of  rules,  its  support  for  multi-valued  relations,  and  conceptual  simplicity.  This  approach  is  less  efficient, 
since  nondeterministic  choice  and  backtracking  are  involved.  However,  it  is  a  local  optimum  point  with 
regard  to  efficiency  because  most  general  unifiers  handle  as  large  a  class  of  cases  in  a  single  step  as  possible. 
Engineers  have  used  Horn  clause  logic  for  many  applications,  although  many  of  these  have  been  in  the  guise 
of  PROLOG  and  have  relied  on  non-logical  features  that  enable  the  use  of  an  imperative  rule  style  familiar 
from  programming. 

Some  weaknesses  of  this  approach  axe  poor  efficiency,  lack  of  support  for  modules,  generalization,  and 
change  propagation,  difficulties  in  dealing  with  negative  information,  and  possible  masking  of  inference 
failures  by  the  closed  world  assumption  and  non-logical  constructs  such  as  cut. 

It  is  hard  integrate  resolution  with  efficient  deterministic  procedures.  Current  strategies  for  achieving 
efficiency  rely  on  imperative  features  and  non-logical  constructs,  which  destroy  referential  transparency  and 
make  rules  hard  to  analyze.  There  do  not  appear  to  be  good  methods  for  integrating  resolution  with  control 
heuristics.  The  control  heuristics  that  exist  are  formulated  in  terms  of  implementation  level  concepts,  or 
abstract  theoretical  concepts,  such  as  orderings  on  function  symbols.  These  are  foreign  to  the  engineers  who 
will  be  using  the  systems,  and  are  difficult  to  use  due  to  lack  of  reliable  and  systematic  guidelines  for  their 

use. 

Negation  as  failure  complicates  the  theory  and  also  makes  rules  harder  to  analyze. 


5  Conclusions 


Lightweight  inference  is  needed  for  engineering  automation,  including  the  promising  reliable  generator  strat¬ 
egy  for  achieving  cost-effective  high  quality  software  (see  Section  1),  and  there  is  reason  to  believe  that  the 
needed  capabilities  are  feasible.  Some  methods  have  been  successfully  applied  (see  section  3.1).  However, 
none  of  the  known  methods  is  completely  satisfactory.  Application  specific  methods  are  needed  for  scalability, 

and  better  ways  to  develop  such  methods  are  needed. 

Areas  for  future  research  related  to  lightweight  inference  include  better  models  of  inference  rules  and 
rule  subsystems,  better  analysis  capabilities  for  rules,  better  synthesis  and  transformation  capabilities  for 
rules,  procedure  synthesis  capabilities  for  rule  compilation,  improved  methods  for  maintaining  inferences 
as  hypotheses  change,  and  parallel  and  distributed  inference  engines  to  support  collaborative  design  and 


engineering  decision  fusion.  .  . 

Cost-effective  improvements  in  software  quality  are  badly  needed  by  society.  The  software  engmee  g 
community  would  be  well  advised  to  demonstrate  practical  realization  of  such  improvements  relatively  soon. 
We  believe  that  the  reliable  generator  strategy  is  a  good  way  to  do  this.  Research  areas  relevant  to  realizing 
the  reliable  generator  strategy  include  improved  formal  models  of  requirements  issues  and  dependencies, 
computable  connections  between  requirements  issues,  software  architectures,  and  program  generation  rules, 
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X“eSnX£“  mles;  compilation  of  pi. 

of  program  generation  rules  g^rators,  and  integration  of  lightweight  inference  with  formal  models 
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Reactive  Verification  with  Queues 

Nikolaj  S.  Bj0rner*tt§ 


Abstract 

reason  about  req’fr®m.ea‘s.of  reactive  systems.  To 

Stanford  Temporal  Prover)  ^  state,  STeP  [3]  (The 

generation  of  invariants  to  bootstrap  verification  and  final!  .a^ams  to  ^compose  the  verification  task, 
with  basic  verificatioa 

of  quauas  in  verifyiog  a  simple  rencSe  “P*  °f  de“m  f“  «*  “«fP* 

Keywords;  Decision  procedures,  temporal  logic  requirements,  reactive  systems. 


1  A  reactive  control  problem 


Santa  Cruz 


xv,  uuucuwaa  me  controller  that  we  develop  in  this  pa- 
per  some  familiarity  with  the  Californian  geography  will 
be  helpful.  In  particular  we  will  assume  that  Santa  Cruz 
is  north  of  Monterey  Bay.  Assume  also  that  the  city 
council  in  Santa  Cruz  has  decided  that  the  boat  traffic 
passing  through  Santa  Cruz  on  its  way  from  Monterey 
should  be  chunks  of  equally  many  submarines  and  sail¬ 
boats  alternating  with  a  regular  period.  A  frustrated 
council  member  asks  Clint  Eastwood  in  Carmel  to  spon¬ 
sor  a  tower  in  Monterey  Bay  to  control  the  flow  of  boats, 
at  which  Clint  asks  him,  voice  rasping,  “Are  you  feeling 
uc  y  today,  punk?  But  that  is  not  our  main  point. 
Figure  1  illustrates  a  possible  scenario  of  the  intended 
flow:  boats  and  submarines  from  the  south  enter  the  bay 
in  any  order,  the  control  tower  has  the  option  to  keep 
the  incoming  vessels  in  the  bay  for  a  while  or  send  them 
up  north,  but  only  in  such  a  way  that  submarines  and 
boats  alternate  with  a  regular  period  of  length  3. 

As  with  many  other  political  forums,  the  council  is 
bitterly  divided  in  Santa  Cruz,  and  is  unable  to  reach  a 
bipartisan  agreement  of  whether  the  length  of  the  period 
should  be  3  or  5.  In  the  present  assembly  those  favoring 
is  soon  nn  for  ro  *-•  ..  j  .  a  Peri°d  of  length  3  has  the  majority.  Since  the  council 

new  council  h/  -n  ?  everyt^nSto  make  sure  that  P°Pular  demand  is  satisfied,  also  should  the 

it  should  be  ll  maJ°f 7  Z  a  Penu  °f  length  5-  A  d6Sign  constraint  **  the  controller  is  therefore  that 
it  should  be  easily  ^configurable  to  whatever  period  N  of  alternation  that  fits  any  assembly. 

CcS£2mkrTdSCCRrSo4rliorttp  nRF°  UB<Sgran*  DAAH04-95-1-0317,  the  National  Science  Foundation  under  grants 

susxtixxtti 
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as  well  as  the  organizers  of  the  workshop  on  Engineering  Automation  for  Computer  Based  Systems. 


Figure  1:  A  network  traffic  controller 
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Since  Clint  cannot  always  sit  in  the  control  tower  we  are  faced  with  the  problem  to  design  a  controller 
program  that  directs  and  redirects  boats  and  submarines  to  the  bay  or  up  north  such  that  the  period  of 
alternation  is  N. 


2  Requirements 

While  pictures  may  give  some  intuition  as  to  what  sort  of  controller  is  to  be  designed  they  cannot  directly 
be  used  to  describe  the  behavior  of  the  controller  over  time.  For  this  purpose  we  use  linear  time  temporal 
logic  because  it  allows  to  capture  requirements  from  an  observer’s  point  of  view,  directly  appeals  to  state 
changes  over  time,  and  is  supported  by  an  adequate  supply  of  model  checking  algorithms  for  finite  state 
systems  and  verification  rules  for  infinite  state  systems.  In  linear  time  temporal  logic  a  formula  is  evaluated 
over  a  computation  sequence  on  the  environment’s  and  system’s  influence  on  observable  variables. 

Linear  time  temporal  logic  allows  for  instance  to  specify  that 

1.  Ships  and  submarines  do  not  alternate  within  distance  N.  Thus,  for  every  sequence  of  at  most  N 
vessels  sent  up  north,  if  the  first  and  last  vessel  in  the  sequence  are  of  the  same  type,  then  every  vessel 
in  the  sequence  is  of  the  same  type. 

2.  Ships  and  submarines  do  alternate  on  distance  N  +  1.  Thus,  for  every  sequence  of  N  +  1  vessels  sent 
up  north,  the  first  and  last  vessel  in  the  sequence  are  of  different  types. 

3.  Every  vessel  sent  up  north  came  from  south. 

4.  The  controller  reacts  on  sufficient  stimulus.  Thus,  if  infinitely  many  submarines  and  ships  have  been 
sent  up  from  south,  then  infinitely  many  submarines  and  ships  are  sent  up  north. 

Linear  time  temporal  logic  allows  to  capture  these  requirements  leaving  fewer  ambiguities.  This  formal¬ 
ization  occupation  alone  is  in  fact  one  of  the  most  rewarding  components  of  a  system  design.  For  instance, 
it  may  reveal  that  the  above  informal  requirements  leave  open  whether  the  controller  is  allowed  to  delay 
vessels  of  its  choice  arbitrarily. 

However,  the  focus  in  this  paper  is  on  verification  support  for  checking  selected  specifications  agsdnst 
proposed  implementations.  We  will  therefore  limit  ourselves  to  the  formalization  of  the  two  first  properties 
which  are  invariants.  Invariants  can  be  specified  with  the  form  where  tp  is  a  first-order  formula,  and  □ 
is  the  always  temporal  operator.  The  judgment  S  □  y?  asserts  that  the  formula  (p  holds  on  every  reachable 
state  of  system  S. 

3  Queues 

A  closer  study  of  the  proposed  controller’s  environment  reveal  that  the  queue  data-type  can  be  used  with 
advantage  to  model  the  flow  and  temporary  storage  of  vessels. 

3.1  Monterey  Bay 

To  properly  preserve  the  wild-life  and  not  disturb  the  singing  (and  occasionally  doped)  amateur  pilots  in 
Monterey  Bay  incoming  vessels  are  stored  in  the  bay  in  a  last-in  first-out  order.  A  suitable  abstraction  of 
the  bay  is  therefore  a  stack ,  or  equivalently  a  list.  Lists  have  standard  constructors  e  (for  the  empty  list), 
cons  to  add  an  element,  and  selectors  head  and  tail.  With  suitable  donations  from  the  Packard  Foundation, 
we  can  always  extend  the  size  of  the  bay  and  therefore  assume  it  has  infinite  capacity. 

3.2  The  coastal  Mother  Road1 

The  flow  of  vessels  is  on  the  other  hand  more  naturally  modeled  using  channels .  Here  the  primitive  operations 
consist  in  appending  items  to  the  end  of  a  channel,  and  taking  items  out  from  the  front,  thus  processing 

1To  continue:  “66  is  the  mother  road,  the  road  of  flight.”  John  Steinbeck,  The  Grapes  of  Wrath. 
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elements  in  a  first-in  first-out  order.  In  the  programming  language  SPL  which  serves  as  one  of  possible  wavs 
to  present  reactive  systems  to  STeP  the  statement 


consumer  4=  v 

has  as  effect  to  put  v  in  the  end  of  channel  consumer.  The  statement 

producer  =»  x 

can  be  executed  when  the  channel  producer  is  non-empty,  and  has  the  effect  of  removing  the  first  element 
from  producer  and  updating  x  to  it. 


3.3  Queues  as  a  common  denominator 


We  can  kill  two  birds  with  one  golf-ball  (on  Pebble  Beach)  by  modeling 
both  lists  and  channels  using  queues.  Queues  are  lists  with  pairs  of 
symmetric  constructors  and  selectors  respectively.  Thus,  symmetric  to 
the  constructor  cons  there  is  a  constructor  revcons,  which  appends  an 
element  to  the  end  of  a  list  instead  of  to  the  front  as  cons  does.  Similarly, 
symmetric  to  head  there  is  a  selector  last.  The  functionality  of  selectors 
and  constructors  is  illustrated  in  Figure  2. 

3.4  Relations  over  queues 

The  most  basic  relation  over  queues  is  undoubtly  equality  between  these. 
Equality  is  however  in  no  way  the  only  relation  one  may  want  to  express 
between  queues.  For  example,  the  test  whether  a  queue  q  contains  ele¬ 
ment  e,  suggestively  written  e  €E  g,  is  another  natural  candidate.  More 
generally  one  can  assert  sub-queue  relationships  using  q  ■<  r  to  assert 
that  queue  q  is  a  sub-queue  of  r.  Special  cases  are  when  q  is  a  prefix 
respective  suffix  of  r.  These  relations  are  illustrated  in  Figure  3. 


Figure  2:  Queue  constructors  and 
selectors 


3.5  Decision  procedures  for  queues 

Automatic  support  for  queues  in  quantifier-free  for¬ 
mulas  with  the  presented  vocabulary  has  been  de¬ 
veloped  in  [2].  A  result  from  this  work  that  we  will 
make  use  of  here  is  a  decision  procedure  for  valid¬ 
ity,  or  equivalently  satisfiability,  for  quantifier  free 
formulas,  where  terms  are  built  using  variables,  to¬ 
gether  with  operations 

e,  head,  tail,  cons,  first,  last,  revcons, 
and  atomic  formulas  are  built  using  basic  relations 
e  G  g,  q  =  r,  q<r,  prefix(g,r),  suffix(g,r)  . 


Moreover,  the  proposed  decision  procedure  can  be  in¬ 


tegrated  (tightly)  with  solvers  for  other  theories,  such 

as  arithmetic,  to  provide  a  combined  validity  checker  figure  3.  Relations  among  queues  supported  by  de¬ 
fer  a  union  of  several  theories.  Space  limitations  pre-  clsl0n  Proce^ures 

vent  us  from  recreating  all  details  here,  but  readers  familiar  with  interactive  verification  may  appreciate  what 
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relief  decision  procedures  give.  For  example,  we  can  use  and  reason  directly  about  revcons(i,a)  instead  of 
defining  it  indirectly: 

revcons(l,o)  =  rev(cons(o,rev(i))) 

rev(l)  =  rev2  (l,  e) 

rev2  (e,i)  =  l 

rev2(cons  ( a,l),m )  =  r  ev2(i ,  cons  (o,  m )) 

In  this  case  we  would  often  have  to  rely  on  heuristic  support  for  inductive  reasoning  to  unwind  the  recursive 
definition  of  rev2. 


4  Implementation 

Figure  4  suggests  an  implementation  of  the  controller.  It  uses  a  stack  to  keep  track  of  vessels  that  cannot 
be  sent  north  immediately,  a  counter  i  to  maintain  how  many  vessels  of  the  same  value  have  been  sent,  and 
a  flag  turn  to  record  whose  turn  it  is.  Symptomatic  to  the  diseases  of  low-level  programming  we  have  used 
booleans  to  encode  the  distinction  between  sailboats  and  submarines.  So  bear  in  mind  that  true  is  shorthand 
for  sailboat,  and  false  is  shorthand  for  submarine. 


const  N 
in  producer 

out  consumer 

local  stack 
local  turn 
local  i 


:  channel  [1..]  of  boolean  where  producer  =  e 
:  channel  [1..]  of  boolean  where  consumer  =  e 
:  boolean  list  where  stack  =  c 
:  boolean  where  -*tum 
:  integer  where  i  =  0 


consumer  *$=  v\ 

procedure  emit(v)  =  i  ~  if  i  +  l>  N  then  0  else  i  +  1; 

turn  :=  if  i  =  0  then  -i turn  else  turn 


Producer  ; 


Router 


loop  forever  do 

[producer  <=  false  or  producer 


local  x  :  boolean 
loop  forever  do 

f£0:  if  head(stack)  ==  turn  A  stack 
then 

[l\i  emit(head($tack))  1 
£2:  stack  :=  tail{stack)\ 


£3:  producer  =>  x\ 

£4:  if  x  =  turn 

then  £5:  emit(x) 

else  £3:  stack  :=  cons (x>  stack) 


Figure  4:  CONTROLLER 

The  implementation  is  described  in  a  simple  programming  language  with  primitives  for  concurrency  and 
communication  via  channels.  It  is  one  of  the  possible  formats  for  presenting  reactive  systems  to  STeP.  STeP 
compiles  the  program  text  into  a  transition  system ,  which  models  each  basic  statement  of  the  program  as 
a  transition.  The  transitions  (atomic  actions)  are  described  using  binary  relations  between  the  present  and 
next  state  values  of  the  system’s  state  variables.  For  example,  the  statement  lz  is  enabled  when  the  control 
counter  l  reaches  3  and  the  channel  producer  is  non-empty.  It  updates  the  control  to  i  :=  4  and  dequeues 
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the  first  element  of  producer  placing  it  in  the  variable  x.  Other  system  variables 
as  a  first-order  relation  the  transition  relation  reads: 


are  unchanged.  Described 


t  =  3  A  producer  e 

A  e  =  4  A  producer'  =  tail  [producer)  A  x'  =  head(producer) 
A  consumer'  =  consumer  A  t'  =  i  A  stack'  =  sfacfc 


Fortunately,  STeP  provides  translations  like  these  automaticaUy  and  behind  the  scenes.  We  use  T  to  sum¬ 
marize  the  transitions  of  system  S,  r  to  access  individual  transitions,  and  pT  for  the  first-order  transition 
relation  associated  with  r.  The  initial  states  of  S  are  captured  using  a  first-order  formula  0.  For  our  program 


producer  =  e  A  consumer  =  e  A  stack  =  e  A  turn  =  false  A  i  =  0  A  £  =  0 


5  Deductive  verification 

The  deductive  methods  of  STeP  verify  temporal  properties  of  systems  by  means  of  verification  rules  and 
verification  diagrams.  Verification  rules  reduce  temporal  properties  of  systems  to  first-order  verification 
conditions  [8].  The  most  widely  used  verification  rule  is  (the  essentially  non-temporal)  inv  given  in  Figure  5. 
reduces  the  verification  of  the  invariant  dp  to  the  first-order  verification  conditions  in  premises  £1  and 


Figure  5:  Basic  invariance  rule  inv. 

B2.  The  condition  B2  is  shorthand  for 

A  OK*)  a  Pt{x,x')  -3-  p(x'))  . 
rer 

6  Generation  of  invariants 

It  is  a  property  of  the  implementation  that  the  stack  variable  contains  only  bits  of  the  same  value.  The  alert 
reader  will  notice  that  Figure  1  is  misleading  in  this  resp'ect,  but  keep  in  mind  that  we  are  only  analyzing 
one  possible  realization  of  the  requirements.  We  can  check  the  property  by  postulating  the  invariant: 


<Pi  •  \3  ((-'head (stack))  £  stack)  (1) 

Note  that  if  £he  stack  is  empty,  then  the  invariant  holds  trivially  although  we  have  left  the  effect  of  head 
under  specified  in  this  case  (not  undefined  as  the  programming  language  centric  convention  is). 

The  invariant  tpi  is  not  inductive,  but  by  using  the  auxiliary  invariants 


V2 :  c£_£3,4  A  (head(stack)  -H-  turn)  =>  stack  =  c  (2) 

<P3  :  atJ5fi  =>  (x  turn)  A  ((head(stack)  **  turn)  -)■  stack  =  e)  (3) 

we  can  use  rule  inv  from  Figure  5  and  the  decision  procedures  for  queues  to  automatically  prove  the  property. 
We  used  the  shorthand  atJ3A  in  place  of  l  =  3  V  i  =  4,  and  (...=»...)  as  shorthand  for  □(...-*...). 

The  invariants  tp2  and  <p3  are  generated  automatically  by  STeP  and  need  therefore  not  be  formulated 
independently  by  the  practicing  verifier.  Generation  of  invariants  and  auxiliary  assertions  [4]  is  one  of  the 
features  STeP  provides  to  bootstrap  deductive  verification.  In  this  case  STeP’s  user  only  had  to  assert 
the  main  property  to  be  verified,  press  a  button  to  generate  invariants,  and  invoke  INV  to  let  the  decision 
procedures  handle  the  sub-goals  automatically. 


-34- 


6.1  Abstraction 

Invariant  generation  and  decision  procedures  play  an  intimate  role  in  an  emerging  practice  in  automatic 
verification  of  infinite  state  systems  using  abstraction  [1,  5].  Invariants  are  generated  from  abstraction, 
which  relies  on  techniques  from  static  program  analysis.  Decision  procedures,  on  the  other  hand,  can  be 
used  to  generate  abstractions  preserving  more  properties  as  they  give  more  expressive  power  to  the  static 
analyzer.  The  coupling  is  loosely  motivated  by  the  picture  below. 


INVARIANTS 


DECISION 

PROCEDURES 


7  Verification 

Suppose  now  that  we  wish  to  express  that  the  bits  in  the  consumer  do  not  change  value  within  distanced. 
Pictorially,  if  x  and  y  are  the  same  in  consumer,  and  the  distance  between  x  and  y  does  not  exceed  N,  then 
any  z  between  x  and  y  must  have  the  same  value. 

consumer 


<N 


Using  a  sub-queue  relation  symbol  d,  operations  head,  and  last,  which  pick  first  and  last  elements  in  a  queue, 
and  a  length  measure  |  |  we  can  express  this  concisely  using  the  invariant: 


s  ;<  consumer 

1  <  \s\  <  N 
head(s)  =  last(s) 


(-ihead($))  s 


The  invariant  is  unfortunately  not  inductive,  but  can  be  established  using  the  auxiliary  invariants  below. 
The  predicate  suffix  states  that  s  is  a  suffix  of  the  queue  consumer. 


□(0  <  t  <  N) 

i  >  0  =>  last{consumer)  —  turn 

i  —  o  a  consumer  ^  e  =r*  last(consumer)  ^  turn 


(5) 

(6) 
(7) 


Z'  (  suffixes,  consumer)  A  1  <  \s\  <  N  )  \  (8) 

O5^5)  l  if  |$1  <  i  then  £  s  else  (i  —  0  — >  turn  &s)J 

The  good  news  is  on  the  other  hand  that  verification  of  both  the  auxiliai? ^  invariants >  and ithe ^inaiii 
specification  proceeds  practically  automatically  thanks  to  the  decision  procedures  for  queues  that  we  deve  P 
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/  (0  <  i  A  *  <  N)  \ 

A  (0  <  i  ->•  last  (consumer)  =  turn) 

A  (  i  =  0  A  ~>(consumer  =  e)  — >•  \ 

V  ~>(last(con5umer)  =  turn)  J 

(  suffix(f  irst(s),  consumer)  \ 

A  1  <  |f  irst(s)|  A  |first(s)|  <  N  I 

* 

if  |f  irst(s)|  <  i 
then  (-ifwm)  £  first(s) 

>  else  (f  =  0  — >  turn  £  f irst(s))  /  .  ,  .  ,  .. 

A  f  s-  consumer  A  1  <  |$|  A  |s|  <  N  -+  \  (-,liead(s))  i  s 

V  head(s)  =  last(s)  -}•  (-ihead(s))  gs  J 
A  head(s)  =  last(s) 

A  s  ;<  revcons(consumer,  turn) 

A  1  <  |s|  A  \s\<N 

/  f  irst(s)  consumer  A  \ 

A  1  <  |first(s)|  A  |first(s)|  <  N J 
head(f  irst(s))  =  last(f  irst(s)) 

\  \  (~>head(f  irst(s)))  £  f  irst(s)  JJ 

S.r(9)TSbfctog  diStan“  "+1  ta  tte  CM““mer  "e  *hn»*  differel11  “stoe «“  “=““*y 

(Vs)  ( suffix(s ,  consumer )  A  i  <  |s|  <  N  =>  head(s)  ^  last(s))  (9) 

(Vs)  (s  ;<  consumer  A  |s|  =  iV+l  =*  head(s)  #  last(s))  (10) 


8  Conclusions 


rrnJ^fn  u  th®  po“t?  ?d  We  ^  the  reader  yet  another  trivial  example  (albeit  not  a  railroad 
crossing  problem)  to  discredit  formal  methods,  or  at  least  our  version  of  it?  Did  we  use  the  right  way  for  the 

requirements  capture,  as  postulated  in  the  abstract?  Did  we  blaze  our  own  trail  to  to  distinguish  ourselves 
rifi  t  ^  be  r6USed  by  the  C°mmUnity  that  does  not  subscrfbe  to  temporal  logic  based  deductive 


..  ,  /first  Purpose  has  naturally  been  to  describe  one  of  the  ways  to  verify  systems  with  STeP,  and  in  par¬ 
ticular  highlight  decision  procedures  which  is  related  to  my  own  technical  interests.  Temporal  verification  in 
this  flavor  consisted  of  several  components:  a  language  for  capturing  requirements,  a  language  and  underly¬ 
ing  model  for  describing  systems,  and  a  verification  methodology  consisting  of  verification  rules,  generation 
oi  invariants,  and  decision  procedures.  The  example  has  been  chosen  carefully  such  that  standard  model 
checking  techniques  could  not  be  applied  due  to  the  non-fixed  parameter  N.  Deductive  methods  are  largely 
insensitive  to  such  generalization. 

But  if  one  is  not  interested  in  verification  of  temporal  requirements  of  a  given  system,  what  do  we  have 
to  otter.  Certainly  the  decision  procedures  for  queues  can  handle  data-domains  independently  of  whether 
we  are  addressing  properties  of  reactive  systems,  functional  programs,  or  high-level  specifications.  The 
decision  procedures  for  queues  have  even  been  used  in  an  extensive  benchmark  for  component  based  software 
retrieval  [6J.  Decision  procedures  offer  the  algorithmic  counterpart  of  inference  from  first  principles,  which 
impedes  the  use  of  any  verification  technology  about  anywhere.  Decision  procedures  also  often  terminate 
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quickly  on  invalid  goals,  at  least  the  ones  I  have  had  the  chance  to  test.  This  is  particularly  helpful  in 
debugging  the  verification  of  a  specification.  Finally,  decision  procedures,  even  when  implemented  only 
incompletely,  is  one  of  the  ingredients  that  can  be  used  for  something  more  fancy  than  the  standard  debugging 
and  code  optimizing  environments  for  software.  If  the  aim  is  to  program  with  constraints,  decision  procedures 

are  again  the  required  core  technology.  /  .. 

In  summary,  I  would  like  to  emphasize  two  points  in  connection  with  this  paper:  First,  formalization, 
which  was  done  only  roughly  in  Section  2,  is  certainly  essential  for  the  documentation  and  success  of  the 
development  of  a  software  based  system.  “See  source  code  for  documentation”,  or  “Its  all  in  my  mind  ,  are 
unfortunately  not  hypothetical  scenarios  -  to  the  authors  own  regretful  experience.  Adapting  an  independent 
formalization  process  allows  to  communicate  and  document  system  requirements  and  architecture.  Formal¬ 
ization  should  naturally  only  be  carried  out  to  the  extent  that  it  contributes  to  the  design  and  analysis  of  the 
constructed  system.  On  the  other  hand,  constructing  a  system  so  that  it  is  amenable  to  formalizable  analysis 
has  never  been  a  disadvantage  (for  me).  Second,  automatic  support  of  high-level  formalizable  frameworks 
adds  value  to  the  development  of  software.  This  may  be  in  the  form  of  compilers  for  high-level  programming 
languages  (ML,  SeqL),  constraint-based  programming  environments,  or  expressive  debugging  took,  such  as, 
deductive  verification,  extended  static  checkers,  and  model  checkers..  The  technology  for  the  latter  is  reaching 
a  stage  today  where  they  can  be  used  with  some  benefit  in  the  design  cycle  along  with  standard  debugging 
and  development  tools.  Naturally,  decision  procedures  play  a  central  part  of  this  process. 
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Abstract 

Despite  the  enormous  strides  made  in  automatic  verification  technology  over  the  past  decade 
and  a  half,  tools  such  as  model  checkers  remain  relatively  underused  in  the  development  of 
software.  One  reason  for  this  is  that  the  bewildering  array  of  specification  and  verification 
formalisms  complicates  the  development  and  adoption  by  users  of  relevant  tool  support.  This 
paper  proposes  a  remedy  to  this  state  of  affairs  in  the  case  of  finite-state  concurrent  systems 
by  describing  an  approach  to  developing  customizable  yet  efficient  verification  tools. 

1  Introduction 

The  field  of  automatic  verification  of  finite-state  systems  has  experienced  tremendous  ad¬ 
vances  over  the  past  decade  and  a  half,  as  efficient  verification  algorithms  have  been  devel¬ 
oped  and  associated  tools  built  and  applied  to  case  studies  of  substantial  complexity  [13, 18]. 
Within  the  hardware  community,  commercial  interest  in  these  tools  has  even  begun,  as 
companies  such  as  Intel,  National  Semiconductor  and  Chrysalis  Symbolic  Design  have  in¬ 
corporated  the  use  of  automatic  verification  tools  in  their  design  processes.  Despite  these 
developments,  however,  verification  technology  remains  largely  unused  in  the  software  com¬ 
munity  in  general,  even  in  areas  such  as  process  control  and  communications  protocols, 
where  finite-state  models  form  the  basis  of  system  implementations,  thereby  rendering  them 
candidates  for  automatic  analysis. 

One  may  identify  several  cultural  and  technical  reasons  for  this  lack  of  uptake  within 
the  software  community:  unavailability  of  training,  uncertainty  about  how  to  deploy  formal 
analysis  in  the  software  process,  skepticism  about  the  benefits  versus  the  costs  of  formal 

‘Research  supported  by  ARO  grant  P-38682-MA,  AFOSR  grant  F49620-95-1-0508,  NSF  Young  Investiga¬ 
tor  Award  CCR-9257963,  NSF  grant  CCR-9505562,  NSF  grant  CCR-9996086,  and  NSF  grant  INT-9603441. 
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analysis,  etc.  While  it  is  beyond  the  scope  of  this  paper  to  discuss  all  these  concerns,  we 
do  note  that  even  users  who. might  be  interested  in  formal  approaches  to  the  analysis  o 
finite-state  concurrent  systems  are  confronted  with  the  following  issues. 

1.  Which  design  notation  should  be  used  for  representing  software  artifacts?  The  liter¬ 
ature  contains  a  number  of  proposals,  including  Esterel  [1],  Statecharts  [24],  SDL  [9], 
LOTOS  [29],  and  CSP  [25],  to  name  only  a  few  .of  the  best-known  ones. 

2.  How  should  requirements  for  designs  be  formulated?  Again,  the  literature  contains 
numerous  suggestions,  including  finite-state  machines,  Computation  Tree  Logic  [12] 
and  Linear  Temporal  Logic  [27],  to  name  a  few. 


This  bewildering  array  of  choices  has  two  negative  consequences.  The  first  is  that  no  specifi¬ 
cation  formalism  has  yet  achieved  a  “critical  mass”  of  users  The  second  is  that  tool  support 
(necessary  for  any  serious  use  of  formal  analysis)  remains  fairly  primitive  from  a  user  s  per¬ 
spective;  the  fact  that  no  “market”  exists  for  any  single  formalism  has  dissuaded  tool  builders 
from  expending  the  resources  needed  to  build  sophisticated  and  usable  tools.  The  lack  of 
appropriate  tool  support  has  in  turn  retarded  the  uptake  of  automatic  verification  among 

software  ^d es^gners.^  &  framework  for  developing  generic  and  customizable  verification 

tools  and  investigate  its  use  as  a  basis  for  efficient  automated  analysis  of  finite-state  systems. 
The  framework  is  intended  to  ease  dramatically  the  task  of  developing  usable  tools  for 
(operationally  based)  verification  formalisms,  thereby  removing,  at  least  in  principle,  one 
obstacle  to  the  increased  adoption  of  verification  technology  in  practice. 


2  Fundamental  Concepts  in  the  Verification  of  Finite- 
State  Systems 

This  section  sketches  the  concepts  we  deem  fundamental  for  the  analysis  and  ventatom  of 
finite-state  systems.  The  first  two  involve  approaches  to  establishing  that  finite-state  sy 
satisfy  their  specifications.  In  general,  one  may  identify  two  schools  of  thought  regaxdmgt 
verification  of  systems:  logic-based  approaches  and l  refinement-based 

typically  involve  the  use  of  a  temporal  logic  for  describing  desired  systern  properties  one 
then  ures  a  model  checker  to  determine  whether  or  not  the  properties  hold of  a  putatwe 
implementation.  The  latter  uses  abstract,  “high-level”  systems  as  speafications  one  then 
proves  an  implementation  correct  by  showing  that  it  “refines”  such  a  spccification^.^  ^ 
related  to  it  be  an  appropriate  behavioral  equivalence  or  preorder).  Both  approaches  ha 
theiruses,  and  a  number  of  temporal  logics  and  behavioral  relations  have  been  proposed  for 

venficationpurposra  (le^ta^to  these  approaches?  In  the  case  of  model  checking,  ™ 

others  [22  31  posit  that  the  modal  mu-calculus  [26]  constitutes  an  expressive  an 

basis  This  loric  provides  simple  modalities  and  propositional  constructs  together  with 
basis.  This  logic  provite  simp  model-checking  algorithms  have 

bet ^  [2,  !9, 21],  and  other  temporal  logics  have  efficient 
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systems  are  related  by  bisimulation  equivalence  (simulation  preorder)  [30,  23, 11],  and  other 
relations  may  be  computed  efficiently  by  combining  decision  procedures  for  (bi) simulation 
wit  appropriate  transformations  on  the  underlying  finite-state  systems  [10, 16].  In  addition 
general  theories  of  bisimulation-based  “diagnostic  information”  that  explain  why  a  system 
fails  to  refine  another  have  been  developed  [11]. 

The  final  fundamental  notion  involves  the  definition  of  design  notations  for  representing 
finite-state  systems.  In  order  to  be  usable  as  a  basis  for  formal  analysis,  such  notations 
must  m  addition  to  having  useful  constructs,  be  equipped  with  a  formal  semantics  that 
unambiguously  defines  an  association  between  “programs”  in  the  language  and  finite-state 
machines  representing  their  behavior.  To  give  such  a  semantics,  we  advocate  the  use  of 
operational  semantic  in  general,  and  structural  operational  semantics  (SOS)  [31]  in 
particular,  as  a  rigorous  yet  conceptually  clear  presentation  style.  SOS  presentations  consist 
of  collections  of  inference  rules  that  specify  the  single-step  transitions  of  systems  in  terms 
of  the  execution  steps  of  their  components.  Languages  such  as  CCS  [28],  LOTOS  [29]  and 
CSP  [25]  have  such  a  semantics,  and  it  has  become  the  preferred  style  for  defining  the 
“f  °f  cons^ructs  in  process  algebra  [5].  An  additional  virtue  of  operational  semantics, 
and  SOS  in  particular,  involves  its  connection  with  simulation:  an  operational  account  of  a 
language  implicitly  defines  how  to  simulate  “programs”  in  the  language. 


3  The  Concurrency  Workbench  And  Analytical  Gener- 
icity 

The  previous  section  presented  a  proposed  foundation  for  the  automatic  verification  of  finite- 
state  systems.  In  order  for  this  theory  to  be  of  practical  as  well  as  theoretical  value,  one 
must  show  that  it  can  be  used  as  a  basis  for  the  development  of  usable  verification  tools. 
This  section  and  the  one  following  explore  this  issue  by  describing  our  experience  with  two 
associated  automatic  verification  tools:  the  Concurrency  Workbench  of  North  Carolina  [17] 
and  the  Process  Algebra  Compiler  of  North  Carolina  [15], 

The  Concurrency  Workbench  was  originally  conceived  as  a  “laboratory”  for  experiment¬ 
ing  with  different  techniques  for  verifying  finite-state  systems  represented  in  CCS  [16].  The 
tool  incorporated  implementations  of  bisimulation,  prebisimulation  and  mu-calculus  model¬ 
checking  algorithms  and  provided  support  for  easily  customizing  these  algorithms  to  calculate 
a  variety  of  different  behavioral  relations  and  for  introducing  new  temporal  constructs.  The 
original  public  release  of  the  system  suffered  from  several  performance  bottlenecks,  and  con¬ 
sequently  while  it  was  easy  to  customize  it  could  be  frustratingly  inefficient.  The  tool  was 
nevertheless  used  successfully  in  the  analysis  of  several  case  studies  [7], 

The  Concurrency  Workbench  of  North  Carolina  (CWB-NC)  [17]  represents  a  completely 
re-implemented  version  of  the  original  CWB.  Our  goal  in  this  effort  has  been  to  show  that  the 
inefficiencies  of  the  CWB  were  due  not  to  its  genericity  (as  some  have  suggested)  but  rather  to 
lower-level  implementation  issues  that  can  be  addressed  in  a  design-language-  and  analysis- 
independent  manner.  Consequently,  the  CWB-NC  retains  the  (pre)  bisimulation/mu-calculus 
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orientation  of  the  original  CWB,  but  it  contains  more  efficient  implementations  of  the  low- 
level  routines.  It  also  cleanly  separates  routines  that  are  design-language-specific  (parsers, 
unparsers,  transition  calculation)  from  those  that  are  independent  of  the  design  notation 
(bisiniulation,  model  checking,  simulator)  in  order  to  facilitate  modifications  to  the  lan¬ 
guage  that  is  supported.  Figure  1  contains  a  representation  of  the  architecture  of  the 
CWB-NC.  The  CWB-NC  has  been  publicly  available  since  September  of  1996  from  URL 
www4.ncsu.edu/~rance/WWW/cwb-nc.html  and  has  been  used  in  the  analysis  of  several 
reasonably  sophisticated  case  studies  [14,  20].  While  a  detailed  comparison  has  not  been 
conducted,  preliminary  evidence  suggests  that  the  CWB-NC  is  2-3  orders  of  magnitude 
faster  than  an  earlier  version  of  the  CWB  (specifically,  version  6.0). 


Figure  1:  The  Architecture  of  the  CWB-NC. 


4  The  Process  Algebra  Compiler  and  Language  Gener- 
icity 

Our  experience  with  the  CWB  and  CWB-NC  suggests  that  (pre) bisimulations  and  the  modal 
mu-calculus  form  an  efficient  yet  easily  customizable  basis  for  system  verification.  However, 
changing  the  design  language  supported  by  the  CWB-NC  requires  substantial  and  delicate 
recoding  in  order  for  performance  to  be  acceptable.  In  order  to  alleviate  the  difficulty  of 
this  task,  the  Process  Algebra  Compiler  (PAC)  project  between  NCSU  and  INRIA-Sophia 
Antipolis  was  undertaken  with  support  from  the  US  National  Science  Foundation  and  IN- 
RIA  [15].  The  PAC  aims  to  produce  efficient  front  ends  for  verification  tools  from  high-level 
descriptions  of  the  syntax  and  semantics  of  the  design  language  the  front-end  is  intended 
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to  support.  The  Process  Algebra  Compiler  of  North  Carolina  (PAC-NC)  constitutes  the 
specialization  of  the  PAC  for  the  CWB-NC. 


The  PAC-NC  takes  as  input  files  defining  the  abstract  and  concrete  syntax  of  a  design 
notation  and  its  operational  semantics  as  SOS  rules  and  generates  SML  code  (the  implemen¬ 
tation  language  of  the  CWB-NC)  implementing  parsers,  unparsers  and  relevant  semantic 

7  a  transition  calculator).  A  user  may  then  insert  these  routines  into  the 
CWB-NC  m  order  to  change  the  design  notation  supported  by  the  tool.  Figure  2  graphically 
depicts  this  process.  It  should  be  noted  that  all  versions  of  the  PAC,  including  the  PAC- 
NC,  use.  the  same  PAC  front  end;  they  differ  only  in  the  code  they  produce,  since  different 
verification  tools  expect  routines  in  different  languages  and  with  different  functionalities. 


CWB-NC 


Figure  2:  The  PAC-NC  Architecture. 


Efficiency  Issues.  The  CWB-NC  makes  extremely  heavy  use  of  the  semantic  routines 
for  a  design  language;  to  construct  an  automaton  from  a  design  language  ‘'program”,  for 
instance,  the  transitions  function  must  be  called  for  each  state.  Consequently,  in  order  for 
the  PAC-generated  front  ends  to  be  usable,  great  care  must  be  taken  to  ensure  the  efficiency 
of  the  automatically-generated  semantic  routines.  To  achieve  this,  the  PAC-NC  combines  a 
general  pattern-matching-oriented  approach  with  two  low-level  optimizations  in  the  semantic 
routines  it  generates.  We  briefly  describe  these  here;  the  interested  reader  is  referred  to  [15] 
for  a  more  detailed  account. 

To  build  a  function  for  a  semantic  routine  from  an  SOS  specification,  the  PAC-NC  first 
analyzes  the  rules  on  the  basis  of  the  design  language  constructs  they  are  applicable  to.  It 
then  generates  a  function  that,  given  a  “program”  in  the  design  language,  determines  the  ap¬ 
plicable  rules,  recursively  calculates  the  semantic  information  for  appropriate  subprograms, 
and  then  uses  the  rules  to  combine  the  results  of  the  recursive  calls  appropriately.  To  make 
this  process  as  efficient  as  possible,  the  produced  routine  also  does  the  following. 

Call  caching.  The  results  of  certain  previous  recursive  calls  are  stored  in  a  table  in  order  to 
avoid  duplication  of  effort.  (Which  call  results  are  cached  in  this  manner  is  presently 
left  up  to  the  user,  although  this  information  could  also  be  determined  by  analyzing 
the  SOS  rules  appropriately.) 

Tree  flattening.  Parse  trees  are  represented  in  a  compact  fashion  in  order  to  facilitate 
hashing  and  equality-checking  on  trees. 

Tables  1  and  2  contain  the  time  and  space  results  of  some  experiments  with  different  PAC- 
generated  front  ends  for  the  CWB-NC.  The  experiments  were  conducted  on  a  180  MHz 
Pentium  Pro  machine  with  64  MB  of  memory.  The  timing  table  records  the  time  needed  to 


-42- 


construct  an  automaton  from  a  given  program,  while  the  space  table  indicates  the  maximum 
heap  size  needed.  The  programs  used  include  the  following. 

802-2:  A  simplified  version  of  the  IEEE  802-2  token  ring  protocol. 

Mailer:  A  version  of  the  electronic  mail  protocol  used  by  the  Computer  Science  Department 
of  the  University  of  Edinburgh  in  the  late  1980s  [6]. 


ATM:  An  account  of  version  3.0  of  the  User/Network  Interface  in  the  ATM  communications 
protocol  [10]. 

Emitter:  A  sender  in  a  communications  protocol. 


Railway  (LOTOS):  A  railway  signaling  scheme. 

Railway  (PCCS):  The  same  railway  signaling  scheme  in  the  PCCS  process  algebra  [14]. 

In  general,  caching  and  tree  flattening  lead  to  significant  improvements  in  timing  behavior. 
Somewhat  surprisingly,  they  also  induce  improved  memory  performance  on  occasion.  This 
seeming  anomaly  results  from  sharing  in  the  parse  tree  representations  that  caching  in  par¬ 
ticular  supports.  It  should  also  be  noted  that  the  benefits  of  tree  flattening  grow  as  the 
syntactic  complexity  of  designs  increases.  Thus,  the  improvement  induced  by  tree  flatten¬ 
ing  in  the  ATM  example  and  the  LOTOS  examples  is  much  bigger  than  in  the  other,  less 
syntactically  elaborate  examples.  Finally,  caution  should  be  used  m  interpreting  the  space- 
usage  results,  owing  to  the  well-known  difficulties  in  the  space  profiling  of  garbage-collected 

languages  such  as  SML. 


Table  1:  Timings  for  PAC-generated  Front  Ends. 

PM  =  “pattern  matching” 

+ C  =  “pattern  matching  and  caching” 

_I_CF=  “patern  matching,  caching  and  tree  flattening 


TIME  (CPU  seconds) 

System  |  Lang.  States  PM  |  +C  | 

+CF  | 

802-2 

CCS 

331  |  3.41 

1.30 

1.55 

Mailer 

CCS 

1616 

9.53 

5.02 

5.56 

ATM 

CCS 

59614 

723.54 

189.44 

83.56 

Emitter  ' 

LOTOSl 

|  5571 

361.35^ 

58.69 

55.06 

Railway 

LOTOS 

|  19724 

1244.61 

363.05 

171.74 

Railway 

PCCS 

11905 

2081;37 

385.53 

319.23 

It  should  be  noted  that  the  original  hand-written  CWB  semantic  routines ;  employed  the 
same  pattern-oriented  approach  to  the  calculation  of  semantic  information,  although  neither 

call  caching  nor  tree  flattening  were  used. 
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PM  =  “pattern  U"8>  ^  PAaS“erated  »«*  Ends. 

+C  =  “pattern  matching  and  caching” 

+CF=  “patera  matching,  caching  and  tree  flattening 


SPACE  (max  process  size  in  MB)  1 

oystem 

Lang. 

States 

PM 

+C 

+CF 

802-2 

CCS 

331 

8.848 

8.000 

9.040 

Mailer 

CCS 

1616 

10.000 

10.768 

11.476 

ATM 

1  CCS 

59614 

54.846 

'”42.144 

54.756 

Emitter 

LOTOS 

5571 

15.256 

14.932 

HL5.128 

Railway 

[LOTOS 

19724 

[38.368 

34.016 

38.880 

Railway 

PCCS 

11905 

21.656 

38.492 

43.180 

5  Conclusions  and  Directions  for  Future  Work 

This  paper  proposes  a  generic  framework  for  the  automatic  verification  of  finite-state  systems 
and  shows  how  efficient  tool  support  may  be  given  for  it.  The  framework  consists  of  three 

basis  fornmodel  (^b,$lmulf ons  33  a  basis  refinement,  the  modal  mu-calculus  as  a 
'  ,d,  checkmg’  and  structural  operational  semantics  as  a  basis  for  defining  the 

semantics  of  design  notations.  The  Concurrency  Workbench  of  North  Carolina  and  the 
Process  Algebra  Compiler  of  North  Carolina  exploit  this  framework  to  provide  efficient  yet 
easily  customizable  tool  support  based  on  these  notions. 

of  pArhlnUtUhe7ef  W?ld  iike  t°  investigate  techniques  for  improving  the  space  utilization 
front  ends-  Recent  work  [3]  also  points  to  an  abstract  basis  for  model 
checking  that  circumvents  the  need  for  defining  translations  in  the  mu-calculus  and  we 

would  like  to  investigate  the  development  of  a  model-checker  generator  based  on  these  ideas 
t  could  also  be  fruitful  to  look  into  the  provision  of  generic  support  for  symbolic  approaches 

foimr?5  tr  ®nenfd  around  Binary  Decision  Diagrams  [8];  steps  in  this  direction  may  be 

Ifc  Z  /’  r  W°Uld  alS°  be  interesting  t0  instigate  techniques  for  generally 

anH  S  S  ofsystems'  mcluding  those  that  pass  values,  exhibit  real-time  behavior, 
and  have  probabilistic  aspects  to  their  functioning. 
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Abstract. 

This  paper  presents  a  candidate  language  solution  for  the  automation  of  data  parallel  solutions  of  concern  to  the  oil 
industry  and  U.S.  Federal  Agencies  involved  in  the  analysis  of  Satellite  Telemetry  Data.  Focus  is  placed  upon  major 
language  issues  facing  the  development  of  the  information  power  grid.  The  paper  presents  an  example  of  the  type  of 
parallelism  desired  in  the  Grid  and  gives  a  JAVA  solution.  The  JAVA  solution  contains  artifacts  of  the  design  of  parallel 
solutions.  The  same  problem  is  then  recast  in  the  high  level  language  SequenceL,  in  which  parallelisms  are  implied.  The 
SequenceL  approach  seems  to  be  a  good  candidate  for  a  Grid  Oriented  Language,  in  that  the  abstraction  relieves  the  problem 
solver  of  much  of  the  burden  normally  required  in  development  of  parallel  problem  solutions. 


The  Need  for  New  Language  Abstractions 

Hardware  improvements  and  the  general  spread  of  computing  and  computer  applications  have  created  opportunities 
for  scientists  and  engineers  to  solve  ever  more  complicated  problems.  However,  there  are  concerns  about  whether  scientists 
and  engineers  possess  the  software  tools  necessary  to  solve  these  problems  and  what  computer  scientists  can  do  to  help  the 
situation. 

The  fundamental  software  tool  for  problem  solving  is  the  programming  language.  A  programming  language 
provides  the  abstraction  employed  in  solving  problems.  In  order  to  keep  pace  with  hardware  improvements,  computer 
scientists  should  continually  address  the  problem  of  language  abstraction  improvement.  When  advances  in  hardware  make 
problems  technically  feasible  to  solve,  there  should  be  corresponding  language  abstraction  improvements  to  make  problems 
humanly  feasible  to  solve. 

In  the  recent  past,  most  language  studies  have  resulted  in  the  addition  of  new  features  to  existing  language 
abstractions.  The  most  significant  changes  have  resulted  in  additions  to  language  facilities  for  the  definition  of  program  and 
data  structures.  These  changes  have  primarily  taken  place  to  accommodate  the  needs  for  concurrent  execution  and  software 
reuse.  Although  it  is  important  to  add  to  the  existing  abstractions  to  satisfy  immediate  technical  problems,  research  also  needs 
to  be  undertaken  to  simplify  and  minimize  existing  abstractions. 

There  are  application  domains  where  the  need  for  simpler  language  abstractions  is  of  vital  importance.  There  are 
estimates  that  less  than  1%  of  the  available  satellite  data  has  been  analyzed.  [4]  There  exists  the  ability  to  acquire  and  store 
the  data,  but  weakness  in  the  ability  to  determine  its  information  content.  Soon  NASA  will  have  satellites  in  place  that,  in 
sum,  will  produce  a  terabyte  of  data  per  day.  A  major  problem  associated  with  the  analysis  of  the  data  sets  is  the  time  needed 
to  write  the  medium-to-small  programs  to  explore  the  data  for  segments  containing  information  pertinent  to  particular  earth 
science  problems.  Software  productivity  gains  in  developing  exploratory  programs  are  needed  in  order  to  enhance  the 
abilities  of  earth  scientists  in  their  efforts  to  grapple  with  the  complexity  and  enormity  of  satellite  and  seismic  data  sets. 
Software  productivity  gains  can  be  accrued  through  languages  developed  out  of  foundational  research  focusing  on  language 
design. 

The  need  for  computer  language  abstraction  improvement  is  even  more  pronounced  given  the  desire  to  develop 
distributed  approaches  to  data  analysis.  Currently,  industry  and  government  agencies  are  paying  a  lot  of  attention  to 
approaches  involving  complicated  data  parallel  solutions.  Data  parallelisms  embody  the  idea  of  "scatter/gather"  approaches 
to  problem  solving.  The  basic  idea  is  to  have  a  Single-Instruction-Multiple-Data  (S1MD-)  type  architecture  where  a  single 
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program  executes  on  multiple,  networked  processors.  Each  processor  analyzes  a  piece  of  a  large  data  set  (i.e.,  the  data  set  is 
scattered  among  several  processors)  and  when  processing  on  the  partial  data  sets  is  completed,  the  partial  solutions  are 
assembled  (i.e.,  gathered)  to  produce  a  single  large  solution  set.  This  “scatter/gath’bapproach  to  computing  has  been  verv 
successful  in  the  analysis  of  seismic  data  sets.  y 

Prior  to  the  SIMD  approach,  the  oil  industry  would  analyze  entire  data  sets  on  a  single  "super  computer."  The  SIMD 

’s  and  has  since  resulted  in  cheaper  and  faster  processing  of 

seismic  data  sets.  These  data  sets  are  used  to  determine  which  sites  companies  should  lease  for  their  offshore  drilling 
activities.  The  seismic  data  sets  (upon  which  scatter/gather  approaches  have  proven  to  be  successful)  have  quite  a  bit  in 
common  with  the  satellite  telemetry  data  sets  that  NASA  and  other  federal  agencies  acquire  and  store.  There  is  a  major  effort 
to  generalize  the  SIMD  architecture  by  developing  a  super  system  that  could  employ  idle  resources  on  the  World  Wide  Web 
The  effort  is  generally  called  the  Information  Power  Grid  or  the  Grid  for  short. 

Background  on  The  Information  Power  Grid. 

The  Information  Power  Grid  is  a  major  effort  being  funded  by  a  number  of  U.S.  federal  agencies  including  NASA 
and  the  NSF.  The  goal  of  this  effort  is  to  establish  a  computing  infrastructure  on  the  world  wide  web,  providing  powerful 
supercomputing  level  resources  to  any  user  connected  to  the  web.  ‘The  grid  will  connect  multiple  regional  and  national 
computational  grids  to  create  a  universal  source  of  computing  power.  The  word  “grid”  is  chosen  by  analogy  to  the  electric 
power  grid,  which  provides  pervasive  access  to  power. . [8] . 

One  way  to  envision  the  goal  of  this  effort  is  to  imagine  a  web  browser  button  that  would  allow  the  user  to  submit 
programs  for  execution.  In  an  ideal  case,  the  program  would  be  analyzed  to  determine  the  parallelisms  it  contains.  Then,  a 
suitable  distributed,  parallel  architecture  would  be  configured  by  seizing  idle  processors  connected  to  the  internet  -  the 
envisioned  system  would  provide  to  all  entities  connected  to  the  web,  access  to  teraflop  computing  capabilities. 

Clearly  there  are  a  number  of  technical  challenges  that  face  those  who  are  developing  the  grid.  The  focus  here  is  on 
the  computer  language  issues. 

Powerful  new  strategies  for  supporting  the  development  of  high-performance  distributed  applications  will  be 
needed....  The  application  developer  should  be  able  to  concentrate  on  problem  analysis  and  decomposition  at  a 
fairly  high  level  of  abstraction. . .  To  do  this,  [the  programming  support  systeml  will  need  to  find  every  possible 
type  of  parallelism  within  the  application,  including  data  parallelism  and  task  or  object  parallelism...  From  the 
user’s  perspective,  the  most  appealing  approach  to  program  decomposition  is  automatic  parallelism.  [91 

In  this  paper,  we  will  focus  on  language  solutions  to  the  programming  support  system  referred  to  in  the  preceding 
passage.  We  will  first  show  a  simple  data  parallel  problem  solution  using  JAVA’S  multithreading  features.  We  will  then 
describe  the  very  high  level  language,  SequenceL,  and  indicate  how  the  same  data  parallel  problem  solution  is  easily 
identifiable  in  the  SequenceL  solutions.  One  goal  of  the  paper  is  to  convince  the  reader  that  SequenceL  holds  promise  as  a 
grid-oriented  language. 

Data  Parallelisms  in  JAVA. 

The  key  to  achieving  high  performance  on  distributed-memory  machines  is  to  allocate  data  to  various  processor 
memories  to  maximize  locality  and  minimize  communication.  Data  parallelism  is  parallelism  that  derives  from  subdividing 
the  data  domain  in  some  manner  and  assigning  the  subdomains  to  different  processors.  [9]  Data  parallelisms  (i.e.,  those 
characteristic  of  SIMD-type  architectures)  typically  result  in  the  same  computation  being  performed  simultaneously  on 
subdivided  data  sets,  as  opposed  to  dividing  up  the  computation  itself. 

Consider  the  following  word-search  problem  as  written  for  sequential  execution  in  JAVA: 

String  s  =  "here  is  a  test  string"; 

String  $1  =  "test"; 

char[)  sample  =  s.toCharArray(); 

char[]  find  =  si  .toCharArrayO; 

System.out.println(sample); 

n  =  sample.length; 

nl  s  fmd.length; 

for(i=0;i<=n-n  1  ;i++) 

(System.out.println(s.substring(i,i+nl)); 

if(s.substring(i,i+nl).equals(sl)) 

( System.out.println("  TRUE  =  FOUND  ’);} 

1 


-48- 


The  sample  text  is  a  21  character  string.  In  this  problem,  the  goal  is  to  determine  if  the  4  character  string  “tesf  is  in  the 
sample.  The  linear  search  involves  checking  each  unique  4  character  substring  of  the  sample,  to  see  if  it  is  equal  to  the  string 
“test.  if-statement  is  executed  18  times. 

A  data  parallel  solution  to  this  problem  involves  the  separation  of  the  18  unique  4  character  substrings.  This  is 
accomplished  in  Exhibit  1.  In  Exhibit  1  an  array  of  reference  variables  is  declared  (in  line  33).  The  array  is  based  upon  the 
difference  in  length  of  the  string  being  searched  and  the  length  of  the  string  for  which  the  search  is  being  conducted  (i.e.,  in 
this  example,  the  array  will  consist  of  18  elements).  In  lines  35-38,  the  string  being  searched  is  subdivided  and  used  to 
initialize  the  instance  variables  as  the  18  references  to  the  class  are  instantiated  via  the  class’  constructor  method  wrdsrch2 
(lines  7-12  ).  Once  the  18  instances  are  set  up,  the  concurrent  processes  to  compare  the  strings  are  initiated  (in  lines  42-43  ). 
The  18  comparisons  are  executed  concurrently.  Execution  of  the  main  method  proceeds  no  further  until  the  18  processes  are 
joined  (in  lines  45-48  ).  The  18  instances  of  the  boolean  variable  found  are  then  printed  as  output. 

The  concurrent  solution  to  this  problem  is  not  easily  found  (when  one  studies  the  sequential  version)  and  the 
concurrent  solution  is  difficult  to  design,  write,  and  understand.  Furthermore,  the  concurrent  solution  exhibits  artifacts  of  the 
design  effort  to  produce  the  concurrent  solution.  These  artifacts  are  the  thread's,  try's,  join’s,  and  run().  The  next  four 
sections  of  the  paper  are  intended  to  convince  the  reader  that  the  high  level,  executable  language,  SequenceL  may  provide  a 
more  suitable  abstraction  for  representing  data  parallelisms. 


Introducing  the  SequenceL  Language  Constructs. 

SequenceL  was  introduced  as  an  approach  to  software  development  that  offers  a  different,  and  for  many,  a  more 
intuitive  approach  to  problem  solving.  [2,  3, 4,  5,  6,  7]  The  assumption  underlying  the  design  of  SequenceL  is  that  the  data 
product,  as  produced  by  software,  is  the  true  product  of  the  software  developer. 

Using  traditional  languages,  programmers  write  explicit  algorithms  that  imply  data  products.  The  goal  of  the 
SequenceL  design  effort  is  to  provide  a  language  in  which  specifiers  make  an  explicit  statement  of  the  data  product,  which  in 
turn  implies  the  algorithm.  Whereas  algorithm-writers  must  come  to  know  and  understand  the  implied  data  product,  a  data- 
product  specifier  need  not  know  the  implied  algorithm.  In  SequenceL,  focus  turns  from  the  matter  that  produces  the  product 

to  the  product  itself.  ^  , 

One  of  the  main  difficulties  in  traditional  programming  is  grasping  the  true  nature  of  the  implied  data  product. 
Implied  items  are  elusive  and  often  require  a  large  amount  of  concentration  to  fully  grasp.  The  effort  to  gain  the 
understanding  of  the  data  product  impedes  productivity.  Complex  data  products  are  typically  recursively  or  iteratively 
defined.  Software  engineers  have  long  realized  that  the  construction  of  loops  is  complex  and  costly.  [10]  Bishop  noted  that 
"Since  Pratt’s  paper  on  the  design  of  loop  control  structures  was  published  more  than  a  decade  ago,  there  has  been  continued 

interest  in  the  need  to  provide  better  language  features  for  iteration."  [1]  . 

SequenceL  possesses  no  iterative  constructs  and  accommodates  a  unique  form  of  recursion  where  functions  may 
embed  themselves  among  intermediate  data  results.  SequenceL  is  a  language  for  describing  a  data  product  m  terms  of  both 
form  and  content.  The  difference  between  the  traditional  approach  to  programming  and  the  SequenceL  approach  is 
precisely  the  difference  between  an  implicit  product  and  an  explicit  statement  of  the  product.  Consider  as  an  example  a 
simple  program  to  compute  the  mean  value  of  an  unknown  number  of  data  values.  For  example,  if  the  values  are 
(10,25,30,35,40),  then  the  mean  is  obtained  by: 


Mean  —  (10  +  25  +  30  +  35  +  40)  +  5 

In  the  traditional  approach  one  states  an  algorithm  (i.e.,  a  step-by-step  sequence  of  instructions)  that  will  produce  the  desired 
result.  In  SequenceL, ,  one  declares  the  desired  data  product: 


Traditional  Approach  -  Pseudo  Code 

1.  Read  in  the  numbers,  one  at  a  time, 

counting  them  as  they  are  read. 

2.  Add  the  values  together  (Sum  them). 

3.  Divide  the  sum  by  the  count  obtained 

in  step  (1). 


SequenceL  Approach  -  Pseudo  Code 
Divide  the  sum  of  the  values  by  the 
number  of  values. 


SequenceL  consists  of  three  constructs  that  can  be  combined  in  any  manner  to  declare  a  data  product.  All  SequenceL 
operators  operate  on  and  produce  only  sequences.  Sequences  can  be  scalar  (i.e.,  singleton),  nonscalar  (i.e.,  lists  oi 
singletons),  and  nested  structures  (i.e.,  lists  of  lists).  Nested  structures  can  be  nested  to  any  depth.  ™mn*rison 

The  first  SequenceL  construct  is  realized  in  the  definition  of  the  built-in  arithmetic  and  relational  comp^son 
operators  and  is  called  the  regular  construct.  The  regular  construct  applies  an  operator  to  all  elements  of  the  operand 
sequences,  be  they  singletons,  nonscalars,  or  nested  sequences. 


-49- 


Two  Singletons : 


Nonscalars: 


Nested: 


[8] 

[13] 
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cases  these  operations  execute  in  a  uniform  way:  the  operator  is  applied  to  corresponding  elements  of  the  normalized 
operand  sequences.  In  the  first  two  examples,  the  operator  applies  to  corresponding  elements  of  singleton  sequences:  the  first 
examp  e  having  a  binary  set  of  singletons  and  the  second  example  having  4  singleton  sequences.  The  last  (i.e.,  the  nested) 
example  applies  the  operator  to  corresponding  elements  of  nonsingleton  sequences. 

.  In  the  examples  above  normalization  has  no  affect.  Normalization  affects  nested  operands  that  are  of  varying  levels 
of  nesting  anchor  of  varying  cardinalities.  The  operands  are  normalized  in  terms  of  size,  prior  to  carrying  out  the  assigned 
operation.  In  terms  of  cardinality  or  nesting  differences,  the  elements  of  the  smaller  operands  are  repeated  in  the  order  thev 
occur  until  the  smaller  operand  is  equal  in  size  to  the  largest  operand:  3 
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normalize 


,  A  5-  senerf[ive  construct  allows  for  the  expansion  of  sequences.  The  simple  form  expands  integers  within  some 
bounds.  The  nontrivial  version  expands  values  within  bounds  when  the  values  satisfy  a  constraining  formula: 


Simple 


Nontrivial: 


0 

1 

+(p(p(next)),p(next)) 

8 


0 

1 

1 

2 

3 

5 

8 


The  irregular  construct  applies  an  operator  selectively.  The  selection  may  be  based  upon  the  content  or  the  form  of 
operand  sequences.  Often  a  when-clause  is  employed  in  order  to  accomplish  the  selection.  When  the  condition  of  the  when 
clause  is  true,  the  operator  is  applied: 


l  *(satary(i)JJ) 


when  evatuaiion(i)  >5  } 


The  operation  will  apply  to  each  ith  salary,  when  the  corresponding  ith  evaluation  is  better  than  5. 

Selection  can  also  be  based  upon  the  form  of  operand  sequences.  In  these  cases,  a  Using-clause  accompanies  the 
function.  Consider  the  SequenceL  solution  for  the  matrix  multiply: 
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Mmultiply(Consume(pred(nl,n2),succ(ml,m2)),  Produce(next))  where  next(x,y)  = 


+  ( *  (  pred(x,all),  succ(all.y))) 


Using  x  ,y  From  [l,...nl]  *  [l,...,m2] 


In  this  solution,  subscripts  *  and  y  obtain  their  values  from  an  ordered,  cartesian-like  product  obtained  from  the  sequences  of 
values  from  1  to  nl,  inclusively  and  from  1  to  m2,  inclusively.  The  generative  construct  is  employed  to  produce  the  desired 
sequences.  The  resulting  x,y-pairs  are  [  <1,1>,<1,2>,  ...,<2,m2>,...,<nl,l>,<nl,2>,  ...,<nl,m2>]. 

In  addition  to  the  Cartesian  operator  (*)  employed  in  the  Using-clause  of  the  example  above,  subscnpt  sequences  can  be 
combined  with  an  intersection  (&),  union  (OR),  or  difference  ( \  )  operator.  The  example  above  also  introduces  the  wild-card 
subscript  all,  which  obtains  all  values  of  the  selected  sequence  dimension.  . 

The  individual  (x,y)  values  of  the  resulting  product  matrix  are  computed  as  regular  computations:  summing  the 
sequences  of  products  obtained  by  multiplying  rows  of  a  predecessor  matrix  by  corresponding  columns  of  a  successor  matrix. 

SequenceL  functions  are  built-up  using  the  regular,  irregular,  and  generative  constructs.  These  constructs  can  be 
combined  in  any  manner  and  the  sequences  they  produce  can  be  used  as  operands  or  subscripts  to  operands.  Sequences  and 
functions  can  both  serve  as  the  result  of  a  function’s  execution.  The  final  data  product  will  consist  solely  of  sequences,  whi  le 

■  intermediate  results  can  be  a  combination  of  sequences  and  functions. 

The  functions  themselves  execute  in  a  data  dependent  fashion  based  upon  their  signatures.  Domain  operands  are 
consumed  from  the  database  to  which  a  function  is  applied.  The  next  section  describes  a  computational  model  that  embodies 
a  simplified  version  of  Sequencers  execution  strategy. 


SequenceL  Computational  Model. 

Sequencers  execution  strategy  is  based  upon  a  data  dependency  approach  to  execution.  A  simple  form  ot  the 
computational  model  is  presented  in  this  section.  First,  we  introduce  the  following  sets  and  mappings: 


Set  Definitions  and  Mappings: 

S  =  set  of  all  possible  sequences 

=  set  of  all  possible  function  symbols 

_ 2(pred,succ) 

=  Su  (SxNxS) u (SxN) u (NxS) 

=  2f 
e  n 
N->D 

F-S-»Fu  { undefined } 


N 

D 

F 

n 

p 

H: 

B: 


The  sets  S  and  N  are  the  sets  of  all  possible  sequences  and  all  possible  function  symbols  (i.e.,  SequenceL  Unction  names)., 
respectively.  Set  D  is  the  set  of  all  possible  function  domain  arguments,  expressed  as  the  power  set  of  the  set  {pr  ,  )• 

The  set  II  is  the  power  set  of  all  possible  strings  containing: 


1.  A  sequence; 

2.  a  sequence,  followed  by  a  function  name,  followed  by  a  sequence; 

3.  a  sequence,  followed  by  a  function  name;  or 

4.  a  function  name,  followed  by  a  sequence. 


A  program  P  is  an  element  of  n.  The  mappings  of  the  computational  model  are  as  follows: 

1  H:  which  maps  from  a  function  symbol  to  its  matching  domain  arguments;  and 

2.  B:  which  maps  from  a  function  symbol  and  a  sequence  or  sequence-pair,  to  an  element  of  F. 
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requires  P  to  be  a  nonempty  string  if/s  domain  set  contains  succ:  “  ““  **  SeC°nd  conditional  statement 

Enabled(P)  =  {  afp  I  afp  c ,  P  & 

(H(f)  □  {pred}  =>  a  *  X  &  aeS)  & 

(H(f)  3  {succ}  =>p?i  X&PeS)& 

B(afp)  *  undefined  }; 

Where  X  is  the  empty  string,  =>  is  logical  implication,  and 
C  j  is  a  substring  operator. 


A  computation  replaces  all  enabled  functions  and  their  surrounding  sequences  from  the  program  P  with  the  string  of 
equences  and/or  function  symbols  computed  by  an  enabled  function.  For  any  i.  *  and  *  are  possibly  empty  ^ng^  The 
string  computed  by  an  enabled  function  is  determined  by  the  function  symbol  and  its  argument.!  n  Ja  r  if  ,u  S  ’  Th 

S3££JSP  is  *— • «—  " —»  -» — S3 

Execute(  P )  = 

(Y.ECSOYiBC^)  ...  Y„B(5„)Yn+,  |  P  =718,7282 ...  Y„8nYn+i  &  8, ,82, ....  8„  e  Enabled/  P )} 


if  Enabled  ( P  )  *  0 


Execute/  P  )  =  P  if  Enabled  (  P  )  =  0 

A  total  (proper)  computation  is  defined  as  a  sequence  P.,  P2 
Enabled(P„)  =  0. 


where  P,  is  the  initial  program  and  Pi+1  e  Execute(Pj),  and 


Now  consider  an  example  of  the  execution  of  a  SequenceL  operator: 


P=(4+5)/(5-2) 

Enabled(P)={4+5,5-2 } 

Execute(P)={P',P",P"'}  where  P'=(B(4+5)/(5-2))  =  (9)/(5-2) 

P"  =  (4+5y(B(5-2))  =  (4+5V(3) 
P'"=  (B(4+5)V(B(5-2))  =  (9)/(3) 

Notice  that  P"'  provides  for  the  concurrent  solution  so  that 
P,  =  (4+5)/(5-2),  P2  =  (9)/(3),  P3  =  (3) 


Data  Parallelisms  in  SequenceL. 

Data  parallelisms  in  SequenceL  are  definable  in  a  straightforward  manner  through  the  use  of  the  data  dependent 
execution  strategy  of  SequenceL  functions.  Given  the  following  database  configuration,  the  word-search  example  is 
represented  in  an  intuitive  manner: 
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In  this  example,  the  cardinalities  of  the  predecessor  and  the  successor  are  obtained  in  identifiers  n  and  m,  respectively.  Based 
upon  the  using  clause,  the  predecessor's  subscript  x  obtains  values  (in  order)  from  the  generated  sequences: 

((1.2,3,4],[2,3,4,5],[3,4,5,6],(4.5,6,7],[5.6.7.8].[6,7.8,9],(7,8,9,10].(8,9,10,U],(9,10,1I,12], 

[10, 11, 12, 13], (1 1,12, 13, 14], (12. 13,14,15], ]13, 14,15,161114, 15, 16, 17], [15,16, 17,18], 

(16, 17,18, 19],(17, 18.19,20], [18,19,20, 21]] 

The  using  clause  helps  subdivide  the  larger  data  set  into  18  smaller  sets  —  much  like  the  parceling  of  data  accomplished  in 
lines  35-39  and  7-12  in  the  JAVA  version  presented  in  Exhibit  1.  The  function  results  in  the  following  set  of  relations  being 
added  to  the  Sequence L  program: 

[[here]  -  [test],  [ ere  ]  =  [test],  [re  i]  =  [test],  (e  is]  =  [test],  [  is  ]  -  [test],  (is  a]  =  [test], 

[s  a  ]  =  [test],  [at]  =  [test],  (a  te]  =  [test],  [  tes]  =  [test],  [test]  =  [test],  [est  ]  =  [test], 

[st  s]  =  [test],  [t  st]  =  [test],  [  str]  =  [test],  [stri]  =  [test],  [trin]  =  [test],  [ring]  =  [test]] 

The  concurrent  evaluation  of  the  resulting  conditions  is  now  clearly  implied  due  to  the  computational  model  of  SequenceL  -  a 
model  that  allows  the  execution  of  any  function  or  operator  as  soon  as  the  data  required  for  the  operator  or  function  is 
available: 

[[here]  =  [test]  II  [ere  ]  =  [test]  II  [re  i]  =  [test]  II  [e  is]  =  [test]  II  [is  7  =  [test]  II  [is  a]  =  [test]  II 
[sa]~  [test]  \\  (  at]  =  [test]  II  [a  te]  =  [test]  II  [  tes]  =  [test]  II  [test]  =  [test]  II  (est  ]  =  [test]  II 
[st  s]  =  [test]  II  [t  st]  =  [test]  II  [  str]  =  [test]  II [stri]  =  [test]  II  [trin]  =  [test]  II  [ring]  =  [test]] 

After  concurrent  evaluation,  the  vector  of  boolean  results  remains  in  the  database: 

[false,  false,  false,  false,  false,  false,  false,  false,  false,  false,  true,  false,  false,  false,  false,  false,  false,  false  ] 


The  parallelisms  in  SequenceL  are  more  intuitive  in  that  the  parallelisms  do  not  result  in  the  separation  of  elements  of 
functionality  and,  since  parallelisms  are  implied,  the  solution  does  not  require  the  use  of  additional  constructs  as  is  seen  in  the 
thread,  run(),  try,  etc.  required  in  the  JAVA  concurrent  solution. 


Summary. 

SequenceL  seems  to  provide  a  more  intuitive  approach  to  data  analysis  problems  -  especially  when  parallelisms  are 
required  in  the  solution.  Even  the  most  modem  computing  languages  (e.g.,  JAVA)  are  cumbersome  when  it  comes  to  the 
design  and  understanding  of  parallel  solutions.  Modem  approaches  to  data  analysis  as  exemplified  by  the  goals  of  the  Gn 
project  require  languages  that  can  express  parallelisms  at  a  higher  level  -  languages  for  which  parallelisms  can  be  identified 


automatically.  , 

SequenceL,  a  fully  computable  language,  is  presented  as  a  candidate  Grid  Oriented  Language  -  a  language  ior 
expressing  the  complicated  parallelisms  that  will  dominate  Grid  applications.  SequenceL  is  a  good  candidate  because  one  can 
express  problem  solutions  at  a  high  level  and  because  there  is  little  the  programmer  must  do  in  the  way  of  explicitly  defining 
parallelisms.  Task  and  Vector  parallelisms  are  implied  by  the  SequenceL  evaluation  of  nested  terms  and  regular  expressions, 
respectively.  Data  parallelisms  are  realized  through  an  interaction  of  the  irregular  and  generative  constructs,  which  provide 
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for  the  parceling  of  data,  and  through  the  concurrent  ,, 

functions  and  operators.  Although  the  example  data  Dakllel^r^  ,eX.ecution  stms^  followed  in  the  evaluation  of 
example  scales  up  many  mahUrld  d'™I°p.‘d  in  “s  W" *  ^er  simply 

The  searching  of  image  databases  follows  the  same  narcHinc*  a  ,  L°  Processmg  and  security-based  text  searches 
that  the  objects  for  which  one  is  searching  is  characterized  Sc®“ej(ga*er  approach  to  programming.  The  difference  is 
toe,,  which  drives  ,he  search  much  ^  «*« 

paper.  An  example  of  an  image-based  kernel  Is  Ihe  following  Gaussian  I  ,1?  *  StnDf  Search  Was  d°ne  in  ,his 

detection:  louowmg  Oaussian-Laplacian  operator  often  employed  for  edge 


GL(x)(y) 


n  0.3  ‘ 


(x  2  +  y  2)  6.0 


1- 


2*0.3 : 


0 


C*  2  +  v  2 )  6.0 


2*0.3 1 


2.7183 


“  aPPlUd  f“  Val“  from  '  and >.  The Sequ,nceL  funclion 


corresponds  directly  to  the  mathematical 
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class  wrdsrch2  extends  Thread  ( 
String  text; 

String  target; 
boolean  found; 
inti; 


wrdsrch2(String  in,  String  targ,  intk) 
target=targ; 
text=in; 
found=false; 
i=k; 

1 


public  void  runO  l 

if(text.equals(target)) 

{found  =  true;) 


) 


l 


public  static  void  main  (String  args[))  { 
inti.j.k,  n,nl; 

String  s  =  "here  is  a  test  string"; 

String  si  =  "test"; 

char[]  sample  =  s.toCharArrayO; 

chart)  find  =  sl.toCharArrayO; 

System.out.println(sample); 

n  =  sample.length; 
nl  =  find.length; 

String  send; 

wrdsrch2  w[l  =  new  wrdsrch2[(n-nl)+l]; 


for(i=0;i<=n-nl;i++) 

{send  =  s.substring(i,i+nl); 
w{i)  =  new  wrdsrch2(send,sl  ,i); 

) 

System.out.println("To  Run  "); 

for(i=0;i<=n-nl  ;i++) 

(w(i].startO;l 

for(i=0;i<=n-n  1  ;i++) 

{try  {w{i].joinO;  . 

catch  (InterruptedException  ignored)  {  ) 

) 

System.out.println("The  answer  is:  "); 


for(i=0;i<=n-nl  ;i++) 

{ System.out.println(wp]. found); ) 


)) 

Exhibit  1.  Data  Parallelism  in  a  Word  Search  Problem. 
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ABSTRACT 

The  main  goal  of  this  paper  is  to  outline  a  methodology  of  programming  in  dynamic  problem  domains.  The  method¬ 
ology  is  based  on  recent  developments  in  theories  of  reasoning  about  action  and  change  and  in  logic  programming. 
The  basic  ideas  of  the  approach  are  illustrated  by  discussion  of  the  design  of  a  program  which  verifies  plans  to  control 
the  Reactive  Control  System  (RCS)  of  the  Space  Shuttle.  We  start  with  formalization  of  the  RCS  domain  in  an 
action  description  language.  The  resulting  formalization  Arcs  together  with  a  candidate  plan  a  and  a  goal  G  are 
given  as  an  input  to  a  logic  program.  This  program  verifies  if  G  would  be  true  after  executing  a  in  the  current 
situation.  A  high  degree  of  trust  in  the  program’s  correctness  was  achieved  by 

(a)  the  simplicity  and  transparency  of  our  formalization,  Arcsi  which  made  it  possible  for  the  users  to  informally 
verify  its  correctness; 

(b)  a  proof  of  correctness  of  the  program  with  respect  to  Arcs- 

This  is  an  ongoing  work  under  a  contract  with  the  United  Space  Alliance  -  the  company  primarily  responsible  for 
operating  the  Space  Shuttle. 

{Keywords:  Action  Languages,  Logic  Programming,  Agents} 


1  INTRODUCTION 

The  main  goal  of  this  paper  is  to  outline  a  methodology  of  programming  in  dynamic  problem  domains,  based  on 
recent  developments  in  theories  of  actions  and  change  [14],  [13],  and  [8].  These  theories  provide  a  basis  for  reasoning 
about  worlds  inhabited  by  intelligent  agents,  i.e.,  by  entities  that  have  goals  they  want  to  achieve,  actions  they  can 
perform,  and  knowledge  of  the  effects  of  these  actions  and  of  the  surrounding  environment.  To  perform  nontrivial 
reasoning  an  intelligent  agent  situated  in  a  changing  domain  needs  the  knowledge  of  causal  laws  that  describe  effects 
of  actions  that  change  the  domain,  and  the  ability  to  observe  and  record  occurrences  of  these  actions  and  the  truth 
values  of  fluents1  at  particular  moments  of  time.  One  of  the  central  problems  of  knowledge  representation  is  the 
discovery  of  methods  of  representing  this  kind  of  information  in  a  form  allowing  various  types  of  reasoning  about 
the  dynamic  world  and  at  the  same  time  tolerant  to  future  updates.  Our  description  of  dynamic  domains  will  be 
based  on  the  formalism  of  action  languages.  Such  languages,  first  introduced  in  [11],  can  be  thought  of  as  forma 
models  of  the  part  of  the  natural  language  that  are  used  for  describing  the  behavior  of  dynamic  domains.  An  action 
language  can  be  represented  as  the  combination  of  two  distinct  parts:  an  “action  description  language  and^  an 
“action  query  language”.  A  set  A  of  propositions  in  an  action  description  language,  called  an  action  description, 
describes  the  effects  of  actions  on  states.  Mathematically,  it  defines  a  transition  system  with  nodes  correspon  mg 
to  possible  states  and  arcs  labeled  by  actions  from  the  given  domain.  An  arc  (cr*  ,0,0*2)  indicates  that  an  execution 
of  action  a  in  state  cr\  may  result  in  the  domain  moving  to  the  state  0*2.  An  action  query  language  serves  or 
expressing  properties  of  paths2  of  a  given  transition  system.  The  syntax  of  such  a  language  is  defined  by  two  c  asses 
of  syntactic  expressions:  axioms  and  queries.  The  semantics  of  the  action  language  is  defined  by  specifying, 
action  description  A,  every  set  T  of  axioms,  and  every  query  Q,  whether  Q  is  a  consequence  of  T  in  A  (r  Qr 
This  relation  is  in  general  non-monotonic,  i.e.  addition  of  new  information  to  A  and/or  T  can  force  a  reasoner  to 

1  In  this  paper  by  fluents  we  mean  (time-dependent)  properties  of  objects  of  a  dynamic  domain.  .  .  0f 

2 By  a  path  of  a  transition  system  T  we  mean  a  sequence  •••  iGru^n  such  that  for  any  1  <  t  <  n,  15  8X1 

T.  cq  and  en  are  called  initial  and  final  states  of  the  path  respectively. 
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which  agents  are  expected  to'aa^nd^he^eshed'^^b6'01^^11  ***  USed  by  system  designers  to  specify  domains  in 
about  agents  behavior  and  verify  Us corret  nei  a  ^  *****  Such  ^cations  allow  designers  to  rein 

with  the  knowledge  about  its  domain  and  its  ahil  V  i  SSCri^  IO”a  and  axioms  can  also  be  used  to  supply  an  agent 
to  assimilate  observations,  select  goi  nl  f  ?  ?  aCt‘  Ia  thls  case  this  knowledge  can  be  used  by  the  agent 
also  play  a„  ^  «“  *'“>'<  «t  accordingly.  Action 

say,  if  T  t=A  Q  then  execute  action  a”  refer*  *  V  languages.  A  typical  command  of  such  language 

knowledge  of  the  robot  and  to  the  consequence  relain  of  the'e  de9C*?t]on  *?  and  axioms  T  fining  current 
action  description  languages  will  be  illustrated  bv  thei  l  fresPondlnS  action  theory.  In  this  paper  the  use  of 
This  fa  an  ongoing  wo?k  node  a  cont  “c,  wfah  lllS  0  fo/ modeling  subsystems  of  th.  Space  Shuttle 

operating  the  Space  Shuttle  For  ^r  Wtut  t  l  P“1  <0SA)  '  the  “">P»F  Primarily  responsible  (£ 

Shuttle.  An  ac.L  description  Z  ^  S”“m  <RCS>  «*  «“  X 

to  allow  flight  controllers  to  automatically  verify  plans  for  operation  of  IheRcf  7"  “T""'5  sys"m  ““  used 
with  several  important  characteristics  FW  h  ZTL  l  °peratlo“  f  the,RCS-  0ur  Soal  was  to  create  a  system 
Science,  and  be  easily  modifiable  and  a(w  Vl  ^  ^7  by  people  without  much  Gaining  in  Computer 

by  introducing  users  to  the  syntlx and 2  m°fdelmg  other  subsystems  of  the  Shuttle.  Thi?  was  achieved 

details  of  implementation.  Second  we  wantTd  to  ha^e  a'  v  iTl  lanSuaSes  *nd  by  hiding  all  othe^ 

Partly  it  was  achieved  by  the  stowlidL Ta 7  ^  7  h‘gh  degree  of  trust  5n  the  systems’s  correctness 

for  people  from  the  USA  to  informally  verify  correc tT^  f  of  the  RCS  whic^  made  it  possible 

program  was  written  in  a  \Z^  I ^  representation-  Tha  corresponding  plan  checking 

proven  mathematically.  Thisproof  was  developed  fn  COrrectne^  Wlth  resPect  to  our  representation  was 

advances  in  logic  programming  [Sfsl  m  tnd  21  ZlTrlm  W“tmg  a  progr^  and  ^avily  on  recent 
the  initial  specification  into  an  executable  p’ro^am  Thf  nL  r  implemented  by  gradual  transformation  of 

next  section  we  give  a  short  introduc  £>„  s„P£ *  \  T  msured  correctness  of  these  transformations.  In  the 

modeling  the  RCS  and  give  examples  of  its  Semantl^s  °f  an  actlon  description  language  £0  used  for 

A  containing  description  of  effects  of  actions  whfch T  ^  *ni  consists  of  an  act‘on  description 
of  axioms  describing  the  current  state  of  °Je  system  The  E  T  ^  ““l""*1*-  and  the  collectioa  P 
T  t=A  holds.after(goal,  plan)  where  holds' after!  a  Ui  JiT X lan ‘heck,ng  task  can  be  reduced  to  verifying  that 
the  goal  g  would  be  true  if  q  were  executed”^  The’Jm  /*  ^  seql!f1nce  °  of  act,ons  is  executable  and  that 
languages,  logic  programming  th?  des'erbt bn  of  the  ^  S  ^  1  C°?tain  a  short  intr°d^tion  to  action 

corresponding  correctness  thCCrems  P  S  PrOSram  COmputmS the  consequence  relation  \=A,  and  the 

2  LANGUAGE  £0 

t  “X."  t “ ■ which  c™  “7^  -  «»a  «*-u-  ries«,iPtio„ 

sets  of  symbols:  the  set  F  of  ifuents  fnd  Ibl  .T^r  *  f*"*  “!"al“te  E°  'vhlch  «>nsfats  of  two  disjoint,  nonempty 
By  fluent  literals  „e  mean  fluemf.ld  •  A  »f  “‘'ous.  Signatures  of  this  kind  will  he  railed  action  ai5„af,„s 
ra;/aresra^ 

/si0" 


catises(a,/0,[lx,...,/n]) 
causes([/ll...  ,/„],/(,) 


(1) 

(2) 


impossible^,  [/!,...,/„])  (3) 

proposUionTndt/,00  ^  fe*’ ju  T  In  ^  of  the  Propositions  above,  l0  is  called  the  head  of  the 

were  to  be  executed  in  ’aliti.PkHn  ^  of  ^ the  proposition.  . A  proposition  of  the  type  1  says  that,  if  the  action  a 

situation.  Such  propositions  are  cal?  I JC  1*:"t  71  ho  dj  the  fluenk  literal  /0  will  be  caused  to  hold  in  the  resulting 
says  that  the  truTErnt  literal? Y  ’'T1'  A  Proposition  of  the  type  2,  called  a  static  causa)  law, 

erals,  llt m  an  arbitrary  situation,  s,  is  sufficient  to  cause  the  truth  of /0  in  that 
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situation.  A  proposition  of  the  type  3  says  that  action  a  can  not  be  performed  in  any  situation  in  which  /^  ...  / 
hold.  ’  n 

In  addition  to  the  propositions  above,  we  allow  definition  propositions  which  will  be  viewed  as  a  shorthand  for  specific 
sets  of  static  causal  laws.  Definition  propositions  have  the  form: 


definition^ ,  pi  (4) 

where  l0,...,ln  are  fluent  literals.  The  following  restrictions  apply  to  the  use  of  such  propositions: 

1.  Neither  /o  nor  7o  belong  to  the  head  of  any  of  the  static  or  dynamic  causal  laws. 

2.  There  are  no  definitions  whose  heads  are  contrary  fluent  literals. 

Let  {  definitional 0 ,  /?i) , . . . ,  definition (lo ,  /?„)}  be  the  set  of  all  definitions,  in  an  action  description  *4,  which  contain  Iq 
in  the  head.  The  fluent  literal  l0  is  true  in  any  situation  in  which  at  least  one  of  0's  is  true.  Otherwise  it  is  false.  As 
was  mentioned,  definition  propositions  are  a  shorthand  for  a  larger  set  of  static  causal  laws.  The  above  definitions 
of  /o  can  be  replaced  by  static  causal  laws  as  follows: 

1.  For  each  proposition,  definition^, /?,),  add  a  static  causal  law  causes(P,  l). 

2.  For  each  set  of  literals,  0,  such  that: 

(a)  6  is  consistent, 

(b)  for  each  /?,-  there  exists  a  literal  /  6  Pi  such  that  1  €0,  and 

(c)  there  is  no  subset  of  0  which  satisfies  conditions  (a)  and  (b), 

add  a  static  causal  law  causes(0,l). 

An  action  description  A  of  Bo  defines  a  transition  system  describing  effects  of  actions  on  the  possible  states  of  the 
domain.  By  a  state  we  mean  a  consistent  set  cr  of  fluent  literals  such  that 

1.  o  is  complete; 

2.  <7  is  closed  under  the  static  causal  laws  of  A,  i.e.  for  any  static  causal  law  (2)  of  A,  if  {/1, ...,/„}  C  tr  then 
lo  €  cr. 

States  serve  as  the  nodes  of  the  transition  diagram.  Nodes  c\  and  cr 2  are  connected  by  a  directed  arc  labeled  by  an 
action  a  if  02  may  result  from  executing  a  in  <ri.  The  set  of  all  states  that  may  result  from  doing  a  in  a  state  c  will 
be  denoted  by  res(a,  <7).  Precisely  defining  this  set  for  increasingly  complex  action  descriptions  seems  to  be  one  of 
the  main  difficulties  in  the  development  of  action  theories.  In  case  of  action  descriptions  from  Bo  we  will  use  the 
approach  suggested  in  [18]. 

We  will  need  the  following  auxiliary  definitions.  We  say  that  an  action,  o,  is  prohibited  in  a  state,  tr,  if  A  contains 
a  statement  impossi6/e(a,(/1,  ...,/„])  such  that  [/i,...,/„]  C  cr.  Let  F  be  a  set  of  fluent  literals  of  A.  By  the  causa/ 
closure  of  F  we  mean  the  least  superset,  Cnji(F),  of  F  closed  under  the  static  causal  laws  of  A.  By  E(a,tr)  we 
denote  the  set  of  all  fluent  literals,  lo,  for  which  there  is  a  dynamic  causal  law  causes  (a,  f0,  [/i, .  ..,/„])  in  A  such  that 
[/1 , . . . ,  /n]  Qtr.  We  say  that  a  state  o’  may  result  from  doing  action  a  in  a  state  a  if 

1.  a  is  not  prohibited  in  tr; 

2.  </  satisfies  the  condition  cr'  =  Cnpffcr  D  o7)  U  E(a,  tr)) 

An  action  description  is  called  deterministic  if  for  any  action,  a,  and  state,  cr,  there  is  at  most  one  state,  c7,  satisfying 
that  above  conditions.  An  action  description  is  called  consistent  if  res(a,«r)  =  0  iff  a  is  prohibited  in  cr. 

One  may  observe  that  the  complete  understanding  of  the  formal  semantics  of  Bo  requires  some  effort.  Fortunately 
this  effort  is  not  necessary  for  most  users  of  the  language.  Similar  to  other  programming  and  specification  languages 
the  complete  understanding  is  needed  only  if  one  wants  to  prove  correctness  of  compilers  and/or  various  properties 
of  programs  of  Bq.  Otherwise,  informal  understanding  of  the  meaning  of  propositions  of  Bo  is  sufficient. 
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3  QUERY  DESCRIPTION  LANGUAGE  Q„ 


of  SoTveaform'  ^  "  *ctio”  “Suture  E.  consists  of  two  types  of  expressions:  axioms  and  queries.  Axioms 


initiaUy(l ) 

A  set  r  of  axioms  is  i* '  “«Sjn!  ^ *'0^  riT^  A  TV°  ^  ‘tUe  the  initial  sit“*«on. 

s xzSti  sr*  - *  •*  *«■&«  *  “  » 

A  query  of  Q0  is  a  statement  of  the  form 


(5) 


or 


holds.afttr[l,a) 


(6) 


s"th„e"i'„1Saa„""nt  «ra  r«n  Lent  “ST,  f  u™'  Th,e  f 'm'nl  sa^  «>«  •  c®  be  executed  in  tb,  Wtul 
need  the  following  definitions”  °“ld  “““"fr  be  *™  aft"»a^-  *  the  semantics  of  a"  II 

let  T  be  a  transition  system  over  signature  E„.  We  say  that 

(0  a  path  <70,  . . an,tr„  satisfies  &n  axiom  initially(l)  iff  e  no, 

Set TZ ZZZt at'^fies  ZilSZZZr.TZZ ‘  “  7  *  fot  evetp  path  °f  r  *  «“  form 

s'igratm«TTnd'r“e^ T°”  d“"iption  la"S-S»  over 
axioms  in  A  (symbolically,  r  hx  Q)  if  Q  is  a  consequent  ofrYn  T  ^  °  “  *  »f  a  set  T  of 

In  the  next  section  w.  illustrate  the  us,  of  £.  for  the  design  of  a  plan  checking  system  for  the  RCS. 

4  THE  RCS  DOMAIN 

thY RCS t  fanctioningY'wperiy  rnTtitstf V  T7?,  “pabimi“  fot  tbe  SPa“  Shuttle  while  it  is  in  orbit.  When 
maneuver.  Due  to  the  huge  number  of  combinations  &K  pre‘scnpted  Plans  to  accomplish  any  desired 

for  each  multiple  failure  situation  If  multmle  fail,  °f  ^'  “T  may  °CCUr’  U  is  imPossible  to  pre-script  a  plan 
the  ground  to  develop  the  ^  mission’  U  is  left  up  to  «Woa  controllers  on 

a  tool  to  help  create  and  ver  Hesf  Ins  Z  ?!  if  ^  SerioUS  tepercussions  of  erroneous  plans  make 
case  communication  to  ^^0^12^.^-  T*  *  ,T!  “U'd  ^  be  ““d  bp  “‘ronauts  in 
knowledge  of  the  shuttle’s  syftems,  tL  ,» ilabmT Y Z  ,  .“  TT'  a  wider'  b“  ">“'>■  '«*  i«  depth, 
greatly  increase  the  chance  of  success  In  this  paper  we  <Wrih  °  6fP  P  an  *?uring  a  communications  failure  would 
part  of  the  system  is  currently  nXway)  51"m t0  ,etif)r  pla”s’  <W»k  “> tba  P'a""i"8 

StaSJ  £  taSrSt  1‘5  fuTLToVY  T°”  -Tt'r  toi the  Rcs’  wbich  ““tata  i"f»r- 

illustrative  purposes,  we  will  focus  on  nrono  V  i*  va!veS’  fue  tanks’  electrical  circuits,  and  switches.  For 
«on  of  the  RCS  domain  moddTn hlto?T£il*UAKSZ?A  '°““rn  the^ !witcb's.’  A  more  detailed  descrip- 
Which  can  be  in  several  different  nositioS  fL  I!  wS‘  Jhere  afe  two  types  of  switches  in  the  RCS,  each  of 
second  type  controls  an  electrical  circuit  w  ?  f  f  t/Pf  C°ntr°ls  a  pair  ofvalves-  Each  switch  of  the 
jets  must  be  fired.  The  ability  to  fire  thUe  i  t  V  °Fj  6  S  6  t0  e  to  per^orm  a  maneuver,  one  or  more 
the  position  of  the  switches  Vf£ ^RCS  doml  ^  ^  StateS  °f  the  ValveS  and  circu5ts*  and  therefore  on 
the  position  of  a  switch  Performing  an  Ltw!  f  ff  -  15  °n  ^  T  tyPG  °f  actlon  an  aSenk  can  perform,  changing 
position.  For  each  switch  5  and  S  n  v  fpflippi"f  a  swi.tcl? to  a  pos,tion  causes  the  switch  to  be  in  the  new 
of  the  following  dynamic  ’cfu’saUaw  ^  '  ’  h  **  SWltCh  be  We  wiU  have  the  appropriate  version 

cavscs(ftip(S,  P ),  position(S,  P),  [  ]). 
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Flipping  a  switch  to  a  given  position  also  ensures  that  the  switch  is  in  no  other  position  after  performing  the  action. 
PI  and  P 2  are  two  different  positions  then  the  dynamic  causal  law  below  describes  this  effect. 

causes{flip(S,  PI),  ->position(S,  P2),  [  ]). 

Next  we  have  a  rule  stating  that  it  is  impossible  to  flip  a  switch  to  a  position  it  is  already  in. 
impossible(flip(S,  P),  [position^,  P)]). 

Note  that,  since  there  are  50  switches  in  the  RCS  subsystem,  this  rule  cuts  the  number  of  executable  actions  in  a 
ZTenTAv*™  l°  50’  F°r  any  SWitCh  5  and  valve  V  COntrolled  by  S  we  have  the  follow»ng  Static  causal 


cavses({position(S,  open ), 

->non.functional(open,S), 

-i  stuck(closed,V)], 
openly)). 

The  law  states  that  if  the  switch  5  is  set  to  the  open  position  and  both  S  and  V  are  functioning  properly  then  V  is 
open.  .4/jcs  also  contains  a  similar  causal  law  which  states  when  the  valve  will  be  closed. 

One  may  wonder  why  this  was  not  represented  by  a  dynamic  causal  law  which  stated  that  flipping  the  switch  causes 
the  valve  to  be  open  if  the  proper  conditions  were  met.  This  can  be  explained  by  the  following  example. 

Imagine  we  wish  to  model  the  operation  of  an  ordinary  lamp.  One  is  tempted  to  have  a  dynamic  causal  law  statin* 
that  if  the  switch  is  turned  on,  then  the  light  comes  on.  But  what  if  the  bulb  is  burned  out?  We  could  add  a 
precondition  to  the  law  stating  that  it  only  applies  when  the  bulb  is  good.  This,  however,  is  only  half  the  battle  if 
we  have  an  action  to  change  the  bulb.  We  would  then  need  a  dynamic  causal  law  stating  that  changing  the  bulb 
causes  the  light  to  be  on  if  the  switch  is  on.  Suppose  we  then  update  the  domain  by  saying  that  the  lamp  can  be 
unplugged  and  we  add  a  new  action  to  plug  in  the  lamp.  Both  of  the  previous  dynamic  causal  laws  need  to  be 
updated  and  a  new  law  needs  to  be  added.  Now  consider  a  different  approach.  The  dynamic  causal  laws  simply 
state  that  turning  the  switch  on  causes  the  switch  to  be  on  and  changing  the  bulb  causes  the  bulb  to  be  good.  We 
then  add  a  static  causal  law  stating  that  if  the  switch  is  on  and  the  bulb  is  good  then  the  light  is  on.  Now,  in  order 
to  add  the  information  about  plugging  in  the  lamp,  we  simply  add  a  new  dynamic  causal  law  stating  that  plugging 
m  the  lamp  causes  it  to  be  plugged  in.  We  also  must  modify  the  one  existing  static  causal  law  to  reflect  that  the 
lamp  must  be  plugged  in  for  the  light  to  be  on.  This  approach  is  preferable  for  two  primary  reasons.  First,  as  was 
shown  by  the  example,  it  is  more  elaboration  tolerant.  The  second  reason  deals  with  the  initial  situation.  Using  the 
first  approach,  we  could  have  a  consistent  set  of  axioms  which  stated  that  the  light  was  initially  on  and  the  bulb 
was  initially  burned  out.  Using  the  second  approach,  this  initial  situation  is  not  consistent  since  it  is  not  closed  with 
respect  to  the  static  causal  laws  of  the  domain.  Notice  that  the  above  argument  suggests  the  second  dynamic  causal 
law  above  can  be  better  written  as  a  static  causal  law 

causes([Pl  £  P2,  position^,  PI)],  -.position^,  P2)). 

This  is  indeed  the  case  but  we  stay  with  the  original  representation  since  it  substantially  simplifies  some  of  the  proofs. 

In  our  language,  we  also  allow  definition  propositions.  Certain  circuits  within  the  RCS  must  be  switched  on  in  order 
to  operate.  If  X  is  such  a  circuit  and  S  is  the  switch  that  controls  it,  then  if  the  switch  is  on  and  functioning,  then 
the  circuit  will  be  properly  powered.  This  is  captured  by  the  following  definition  proposition  POWERED  CIRCUIT. 

definition{powered(X), 

[position(S,  on), ->non.fvnctional(on,S)]). 

Note  that  this  proposition  is  similar  to  the  static  causal  law  OPEN  VALVE.  A  definition  proposition  is  used  since, 
unlike  the  law  for  OPEN  VALVE,  the  head  of  POWER  CIRCUIT  holds  if  and  only  if  the  preconditions  are  met. 
This  subtle  difference  can  be  illustrated  by  looking  at  the  precondition  that  the  switch  be  functional.  In  the  case  of 
the  circuit,  if  the  switch  becomes  non-functional  while  the  circuit  is  powered,  the  circuit  will  no  longer  be  powered. 
With  the  valve  the  situation  is  different.  If  the  valve  is  already  open  and  the  switch  fails,  the  valve  does  not  close, 
it  stays  open. 

After  completion  of  the  action  description  of  the  RCS  we  addressed  the  problem  of  computing  the  corresponding 
consequence  relation  which  required  knowledge  of  logic  programming  but  no  additional  knowledge  of  the  shuttle. 
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necessary  for  understanding^Hhis  steo^Th  intr°ducl;i?n  to  the  answer  set  semantics  of  logic  programs  [10] 
powerful  than  the  original  Pure  Prolo^in^V0^  p.roSramm»ng  language  used  in  the  paper  is  substantially  more 

detailed  discussion  of  thfc  language  and  t  *  7?  daSSlCal  ^  nonmonotonic  ^ions.  For  more 

S  language  and  its  applications  to  knowledge  representation  see  [3]  and  [12]. 

5  LOGIC  PROGRAMS 

Instants!1  function  ro^stSindie*1  firSt'°rder  laI^Uage*  is  determined  by  its  signature,  consisting  of  object 
positive  literals  (or  SS  SS  rte  **  T ^ 

- — « -*&  zgs  al  c°ntr-  ,o  '• 

Iq  *  i  •  •  •  i  Imj  not  /m«f  1 1  *  •  * »  not  ln 

n°t  ? a. io*1?1  c?rciive  ‘au*>  « *»■« p,  in- ww»nd  «de  «t  «*  ^ 

' *  — <“  " A  ^  <-}  *» 

(usua  y  enoted  by  capital  letters)  will  be  used  as  shorthand  for  the  sets  of  their  ground  instantiations. 

™™kS  °f  5  L°SiC  Pr°°r,am  "  “l*"8  to  a  collection  of  answer  sets  -  sets  of  ground  literals  over  signature 

semantics  t^ru^m"®  V* ^h,ch  Can  be  held  hy  a  rational  reasoner  on  the  basis  of  rules  of  w.  Under  this 
♦  k  *  j  J  n  be  viewed  as  a  constraint  on  such  beliefs  and  is  read  as  “if  literals  /,  /  are  Wipvp^ 

y  tVaUi,“"  .‘nJr  'e“°n  b5,ieve  lhat  . (.  «  true  ft.  the  Mi™ 

Sf„me  S  of .  W  ,n  T””?'  «C  S  or  er  if  /  6  s;  f  is  /.(«  in  S  if  7  €  S.  I  is  (re,  is  »  (»  N  /,  if  ,  js  'ta  h 
rp  .  f  We  say  that  *  *  answer  to  a  wety  1  is  »« if  ir  [=  /,  no  if  a- 1=  7,  and  tm  Wn otherwise, 

o  give  a  definition  of  answer  sets  of  logic  programs,  let  us  first  consider  programs  without  negation  as  failure. 

inclJionjTubset  Sof  !««”))”*  thst”"1”®  neSatl°"  “  "0l  “  *'  5mallest  <in  the  senK 

(i)  for  any  rule  l0<~h,...,lm  from  ir,  if/1(...,/m  e  S,  then  /0  6  S; 

(ii)  if  S  contains  a  pair  of  contrary  literals,  then  5  =  lit(<r(ir)). 

will  be  denoted  byTns^jr)1  pr°Sram  K  tbat  does  not  conta'in  negation  as  failure  has  a  unique  answer  set  which 

oU^efftom  s“/deUH»g  '°giC  P'°eram  "'i‘h°“t  Vatiab'“'  F°r  a"y  S  °f  m'r*ls' lel  **  be  the  ^  P'°S'am 

(i)  each  rule  that  has  an  occurrence  of  not  l  in  its  body  with  /  €  S,  and 
(n)  all  occurrences  of  not  l  in  the  bodies  of  the  remaining  rules. 

Senlvl  rllrt  c°-  COnta'n  n0t  ’  and  hence  its  answer  set  is  already  defined.  If  this  answer  set  coincides  with  S, 
nen  we  say  that  S  is  an  answer  set  of  tt.  In  other  words,  the  answer  sets  of  sr  are  characterized  by  the  equation 


S  =  ans(jr5). 


(8) 


Lk!P  iam.S, Wltbout  classical  negation  the  answer  set  semantics  coincides  with  the  stable  model  semantics  of  [9].) 
commit*  th;  6  i-)°Ve  definition  of  entailment  in  l°gic  programs  is  purely  declarative.  There  are  different  ways  to 
to  bl  J„„T  e.?u'ment'  In  particular>  under  certab  conditions,  a  simple  Prolog  metainterpreter  can  be  shown 
nrovramm;  7^  respe^tortb.s  entailment.  The  version  of  this  metainterpreter  based  on  a  more  modern  logic 
P  g  mming  language  XSB  [6]  is  also  sound  and  provides  an  even  better  approximation. 
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6  TRANSLATION  TO  LOGIC  PROGRAMMING 

Our  methodology  for  computing  the  consequence  relation  of  £0  is  a  slight  modification  of  a  general  approach  suggested 
in  [11],  [4].  It  is  based  on  translating  a  domain  description  V  (consisting  of  action  description  and  axioms)  into  a 
logic  program  II(X>)  and  reducing  the  computation  of  the  consequence  relation  in  V  to  answering  queries  in  II(P). 
At  the  core  of  the  translation  is  a  collection  of  domain  independent  axioms  formalizing  reasoning  about  effects  of 
actions.  The  development  of  these  axioms  was  substantially  influenced  by  two  decades  of  research  in  nonmonotonic 
logics  and  semantics  of  logic  programming.  This  research  led  to  the  methodology  of  representing  and  reasoning  with 
defaults,  i.e.  statements  of  the  form  “normally,  (typically,  as  a  rule)  elements  of  a  class  a  have  property  p”.  There 
are  several  defaults  which  are  frequently  used  in  reasoning  about  effects  of  actions.  The  most  important  one,  known 
as  the  commonsense  law  of  inertia  [16],  says  that  normally,  things  remain  as  they  are.  Any  axiom  describing  the 
effect  of  an  action  on  a  state  of  the  world  represents  an  exception  to  this  default.  An  agent  reasoning  about  possible 
effects  of  his  actions  on  the  current  state  of  the  world  uses  these  axioms  to  derive  the  changes  that  would  occur  in 
the  current  state  after  the  execution  of  a  particular  action.  The  law  of  inertia  is  used  to  derive  what  does  not  change. 
The  problem  of  constructing  a  formal  framework  which  would  allow  us  to  express  and  reason  with  the  law  of  inertia 
is  called  the  frame  problem.  The  use  of  negation  as  failure  leads  to  a  simple  solution  of  the  frame  problem  for  a 
broad  class  of  dynamic  domains. 

6.1  Domain  independent  axioms 

In  this  section  we  outline  the  set  of  domain  independent  axioms,  II.  We  will  assume  that  the  program  contains  rules 
defining  the  following  relations: 

contrary(FjG)  is  true  iff  F  and  G  are  contrary  fluent  literals; 

defined Jiteral(L)  is  true  iff  L  occurs  in  the  head  of  a  definition  from  the  corresponding  action  description; 
frameJiteral(F)  iff  F  is  a  fluent  literal  which  is  neither  a  defined  literal  nor  the  negation  of  defined  literal. 

The  next  three  rules  define  executable  sequences  of  actions: 

impossz6/e([A  |  R])  impossz&/e(A,P), 
hold„after(P,R). 

impossi6/e([A  |  R])  impo$sible(R). 
executable(R)  <—  noi  impossible{R). 

Here  [A  |  R]  is  standard  Prolog  notation  for  the  list  with  head  A  and  tail  R.  (Recall  that,  since  we  execute  actions 
in  the  list  from  right  to  left,  A  is  the  last  action  to  be  executed.)  The  first  two  rules  state  that  a  sequence  of  actions 
is  impossible  if  either  the  last  action  in  the  sequence  is  impossible  or  if  the  rest  of  the  sequence  is  impossible.  The 
definition  of  executability  relies  on  the  completeness  of  our  domain  description.  It  says  that  if  a  sequence  R  of  action 
is  not  known  to  be  impossible  then  it  is  possible. 

The  next  axiom  determines  what  holds  in  the  initial  state  of  the  domain. 

holds -aftcr(L,  [  ])  init ially(L). 

Here  initially{L)  is  an  axiom  of  Qq. 

The  next  four  rules  determine  the  effects  of  causal  laws  of  the  corresponding  action  description. 

holds -after(L,  [A  \  12])  causes{A,L,P), 

hold -aft  cr{P,R), 
executable([A  |  fZ]). 

The  rule  says  that  a  literal,  L,  holds  as  the  result  of  performing  an  executable  sequence  of  actions  [A  |  12],  if  the 
corresponding  action  description  contains  a  dynamic  causal  law  causes(A,L,P)  and  all  the  preconditions  from  P  hold 
after  the  execution  of  R . 

holds -after  (L,S)  causes^GjL), 

hold -after{G  1 5), 
executable(S). 
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The  rule  describes  the  effects  of  static  causal  Jaws. 

The  next  two  rules  ere  concerned  with  definition  proposition, 

Mis-afier(L,S)  ♦—  definitional,,  P), 
hold.after{P,S), 
execute  ble\s). 

holds. after  (F,  S)  -  contrary(F,  G), 
defined. literal(G), 
not  holds.after(G,S), 
executable(S). 

The  rules  state  that  if  there  i«  a  dofi 

nttVS ““  b0di'  '  “d  *"  ,he  P«~nditicns  from  P 
hold.after([  ],  _). 

hc/d.a/ter([/f  |  Tj,A)~-  Mi s.cfur(U,  A), 

hold.after(T,A).  ' 

sir ,hai  *  -  « -  w 

holds -after(L,  [A  |  /?])  «-  frame. literal(L), 

holds. after(L,  R), 
not  ab(L,A,R), 
executable([A  |  J2J). 

for  definition  propSti"!^'"5  0"'1'  *°  ftam'  fl“e",s'  The  val““  °r°‘M  «uents  ere  fully  determined  by  the  rules 

eWc.li,„Tin  ihe  suttoSrJ iTpSE* 

ab(F,A,  R)*~  conirary(F,G), 
couses(A,G,P), 

hold.after(P,R). 

ob(F,A,R)  i—  contrary[F,G), 
cavses(P,G), 
hold.after{P,[A\R\). 

6.2  Correctness  and  Usage 

tion  1  The  action  description  ARCS  is  consistent  and  deterministic. 
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To  actually  execute  the  logic  program  tt  =  A  U  Y  U  II  we  need  to  have  an  interpreter  capable  of  answering  queries 
in  logic  programs  with  two  negations.  Such  an  interpreter,  I,  can  be  easily  constructed  on  top  of  Prolog  or  XSB.  To 
insure  its  correctness  we  need  to  show  that,  given  a  program  tt  of  the  above  form,  the  interpreter  always  terminates, 
does  not  require  a  so  called  occur  check,  does  not  flounder  (i.e.  does  not  attempt  to  prove  a  goal  of  the  form  not  q 
where  q  contains  uninstantiated  variables),  and  satisfies  several  other  simple  properties.  Fortunately,  the  theory 
of  logic  programming  provides  us  with  a  comparatively  simple  way  to  check  all  these  properties  and  to  prove  the 
following  proposition: 

Proposiition  2  Let  q  be  a  ground  query  and  tt  =  Arcs  U  T  U II  where  T  is  a  complete,  consistent  set  of  axioms. 
Then  given  7 r  and  q ,  the  interpreter  I  answers  yes  iff  tt  |=  q. 

These  results  establish  correctness  of  our  program  with  respect  to  Arcs •  In  order  to  use  the  program,  the  flight 
controllers  need  to  specify  the  current  positions  of  the  switches  and  valves,  state  the  malfunctioning  components, 
and  provide  other  similar  information  which  constitutes  I\  This  requires  knowledge  of  neither  action  description 
languages  nor  logic  programming.  If  needed,  consistency  of  the  input  can  be  checked  automatically. 

7  CONCLUSION  AND  FUTURE  WORK 

We  believe  that  our  experiment  in  the  use  of  action  languages  was  successful.  The  action  language  Co  has  proven 
to  be  simple  to  use  and  understand.  This  was  primarily  seen  in  our  communications  with  people  from  USA.  We 
sent  an  early  version  of  the  RCS  action  description  to  our  contact  there  (a  former  flight  controller  for  the  RCS  with 
some  knowledge  of  logic  programming  but  no  prior  experience  with  actions  languages).  He  was  able  to  spot  several 
errors  simply  by  reading  over  the  description.  He  also  found  the  language  intuitive  enough  that  he  has  since  written 
a  preliminary,  more  technically  detailed,  domain  description  for  another  of  the  shuttle’s  subsystems,  using  the  RCS 
action  description  as  his  only  guide. 

The  mathematical  theory  of  action  languages  and  logic  programming  proved  to  be  sufficiently  developed  to  allow 
us  to  prove  the  properties  of  our  system.  As  was  intended,  elements  of  logic  programming  were,  for  the  most  part, 
hidden  from  the  end  users.  Logic  programming,  however,  played  a  bigger  role  than  expected  during  the  formalization 
of  the  RCS  domain.  We  also  found  that,  in  this  domain,  in  order  to  properly  specify  some  of  our  propositions,  we 
needed  to  use  recursive  rules  similar  to  that  used  in  the  definition  of  transitive  closure.  It  remains  to  be  seen  if  this 
can  be  avoided  without  a  substantial  complication  of  representation.  So  far  we  were  not  able  to  do  that,  which  may 
point  to  the  usefulness  of  logic  programming  languages  even  in  the  specification  phase  of  the  project. 

Another  interesting  direction  of  research  suggested  by  this  experiment  is  the  discovery  of  more  powerful  and  preferably 
syntactic  conditions  which  would  guarantee  consistency  and  determinism  of  an  action  specification.  Ultimately,  we 
wish  to  create  an  interface  which  would  allow  an  expert  in  a  given  domain  to  create  an  action  description  with  only 
minor  knowledge  of  logic  programming  and  permit  end  users  to  use  the  system  with  only  knowledge  of  the  interface. 

In  order  to  provide  an  even  more  useful  tool,  we  are  currently  working  to  expand  this  system  in  several  directions. 
Our  first  goal  is  to  expand  the  system  by  adding  a  diagnostic  component.  This  would  be  used  when  a  sequence  of 
actions  was  actually  performed  but  unexpected  results  were  observed.  Using  the  action  description,  we  would  like 
the  system  to  be  able  to  determine  what  failure  or  failures  may  have  occurred  which  would  explain  the  observed 
behavior. 

The  second  direction  for  further  work  concerns  planning.  While  the  current  system  can  verify  plans,  it  would  be 
beneficial  to  be  able  to  generate  plans  as  well.  We  would  like  to  be  able  to  provide  the  system  with  the  current 
situation  and  a  goal(  a  set  of  axioms  and  a  query  from  the  language  of  Qo)  and  have  it  generate  a  plan  to  achieve 
the  goal  from  that  situation. 
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The  role  of  observations  in  probabilistic  open  systems 

Murali  Narasimha*  Ranee  Cleaveland*  Purushothaman  Iyer* 


Abstract 

This  paper  considers  a  logic,  based  on  the  modal  mu-calculus,  for  describing  properties  of  probabilistic  open 
distributed  systems  and  develops  a  model-checking  algorithm  for  determining  whether  or  not  states  in  finite-state 
probabilistic  systems  satisfy  formulas  in  the  logic.  The  central  contribution  of  the  paper  is  a  semantics  that 
distinguishes  between  observations,  the  meaning  of  a  temporal  formula,  and  its  measure.  The  ensuing  model- 
checking  problem  reduces  to  the  calculation  of  a  (particular)  solution  to  a  system  of  non-linear  equations. 


1  Introduction 

The  era  of  net-centric  computing  is  herer  fueled  by  easy  to  use  applications.  In  the  near  future  the  number  of 
network-based  applications  is  expected  to  grow  exponentially.  These  applications  mix  audioTvideo  and  textrandr 
consequentlyrmake  great  demands  on  the  network  traffic.  Consequentlyrthe  eventual  success  of  these  applications 
will  depend  upon  quality  of  service  (QoS)  guarantees  that  can  be  provided  to  the  end-users.  Not  coincidentally!? 
military  applications  (such  as  command  and  control)  have  similarrthough  even  more  stringentrservice  requirements. 
Use  of  formal  methods  for  developingTand  checkingrdesign  specifications  of  concurrent  systemsrand  for  conformance 
testing  of  the  implementationsrhas  gained  currency  over  the  past  decade.  There  have  been  several  success  stories 
reported  in  the  literature  [5].  Howeverrthese  mathematics  based  techniques  have  been  restricted  to  reasoning  about 
qualitativeri.eTfunctionairaspects  of  distributed  system.  In  this  note  we  will  consider  how  specifications  of  open 
distributed  systems  may  be  structured!?  and  how  QoS  requirements  of  such  systems  may  be  stated.  The  mam 
contribution  of  this  paper  is  a  novel  technique  for  describing  the  semantics  of  open  distributed  system  specifications 
containing  probabilistic  information.  Our  semantic  technique  allows  a  precise  calculation  of  the  probability  with 
which  a  temporal  property  of  an  open  distributed  system  holds.  The  paper  is  organized  as  follows:  in  Section  2 
we  briefly  describe  the  specification  and  requirements  language  for  non-probabilistic  open  distributed  systems.  In 
Sections  3  and  4  we  show  how  the  specification  and  the  requirements  languagerfrom  Section  2I?can  be  extended  to 
probabilisticropen  distributed  systems.  We  follow  that  with  a  comparison  of  our  semantics  with  extant  work.  In 
Sections  6  and  7  we  discuss  probabilistic  model-checking  and  our  goals  for  future  work. 


2  Specifying  open  distributed  systems  and  their  requirements 

In  generairthe  literature  on  concurrent  systems  distinguishes  between  open  systems  and  closed  systems.  The  former 
may  require  interaction  with  their  environments  in  order  to  make  progress;  the  latter  are  self-contained.  Semanticallyl 
the  difference  between  these  kinds  of  systems  is  reflected  in  the  mathematical  models  developed  for  them.  Open 
systems  are  often  represented  using  labeled  transition  sysiemsTwhich  may  be  thought  of  as  finite-state  machines  whose 
transition  labels  represent  capabilities  for  interaction  with  the  environmentrand  which  are  used  as  mathematical 
entities  to  provide  semantics  to  calculi  based  on  process  algebras  such  as  CCS  and  CSP  [6T12T1).  CW  systemsr 
on  the  other  handrare  usually  modeled  using  Kripke  dnidtirnTwhich  may  be  thought  of  as  node-labeled  directea 
graphs  whose  vertices  correspond  to  system  states  and  whose  edges  represent  execution  steps.  The  vertex  laoei 
contain  information  that  is  true  of  the  state.  Typical  examples  of  open  systems  include  communication  protocols 
which  require  a  user  to  invoke  a  service  primitive  before  engaging  in  any  activity.  Closed  systems  include  contro 
systems  in  which  a  controller  and  the  process  being  monitored  interact  only  with  each  other. 

»Dept  of  Computer  Science,  North  Carolina  State  University,  Raleigh,  NC  27695. 
tDept  of  Computer  Science,  State  University  of  New  York,  Stony  Brook,  NY  11794-4400 . 
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dataS  =  Send  data 
data  =  Receive  data 

ack  =  Receive  Ack 
ackS  =  Send  Ack 


data  Out 


Figure  1:  A  lossy  half-duplex  line 


data  In 


Figure  2:  An  architectural  view  of  a  communication  system 


ConsiderlYor  examplerthe  communication  medium  of  a  network  system.  A  half-duplex  lineFwhich  takes  messages 
at  one  end  and  (sometimes)  delivers  it  at  the  other  endrcan  be  succinctly  represented  by  the  finite  state  machine  in 
Figure  1.  The  self-loop  transition  from  state  0  to  state  0  labelled  data  models  the  act  of  the  communication  medium 
which  receives  a  data  message  from  the  environment  and  drops  it.  The  sequence  of  transitions  from  state  0  to  1  and 
back  to  0  characterizes  the  behavior  of  the  medium  which  accepts  a  message  from  its  environmentTand  faithfully 
delivers  it.  As  can  be  observed  the  machine  responds  to  input  (data  or  ack)  from  the  environment.  It  is  this  notion 
of  external  controiror  external  non-determinismrthat  characterizes  the  open  system  model. 

ClearlyTthe  communication  medium  is  merely  a  part  of  an  whole  systemr  which  also  includes  a  sender  and  a 
receiver.  One  can  obtain  a  system  by  composing  the  three  processes  together.  The  three  sub-systems  now  act  in 
concert  with  each  otherrand  present  the  view  of  a  single  system  to  an  external  observer  (see  Figure  2).  Assuming  that 
the  sender  and  the  receiver  act  as  an  intermediary  between  the  user  and  the  communication  medium  the  behavior 
of  the  entire  system  is  equivalent  to  the  behavior  of  the  communication  medium  depicted  in  Figure  1. 

FormallyFLabelled  transition  systems  are  defined  as  follows: 

Definition  2.1  A  Labelled  Transition  System  (LTS)  L  =  ( S,Ad,-+ )  where  5  is  a  set  of  statesIMci  is  the  set  of 
actions  that  the  system  L  may  engage  in  and  — >C  S  x  Act  x  S  is  the  transition  relation  expressing  permissible  actions 
of  the  system  L. 
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2.1  A  logic  for  stating  requirements 

Temporal  logics  have  traditionally  been  used  to  reason  about  closed  systems;  more  preciselyrKripke  structures  (see 
abZ)  have  been  used  as  models  for  these  logics.  The  p-calculus  [9]ron  the  other  handEpernuts  properties  o  open 
systems  (labeled  transition  systems)  to  be  formulated.  The  logic  is  very  sparser  syntactically  ;  m  addition  to  the 
usual  boolean  operators^  includes  modalities  indexed  by  sets  of  transition  labels  and  schemes  for  defining  formulas 
recursively.  Thusltor  example^  state  in  a  labeled  transition  system  satisfies  [S]*  if  every  transition  from  the  state 
labeled  by  an  element  of  S  satisfies  ^rand  it  satisfies  {S}4>  if  it  has  some  transition  labeled  by  an  element  of  S 
thlt  satisfies  4>.  Recursive  formulas  have  the  form  or  vX.<f>.  The  former  represents  the  least  solution  to  the 
“equation”  X  =  4>  and  is  useful  in  expressing  liveness  properties;  the  latter  corresponds  to  the  largest  solu  ion  to 
tJ  same  equation  and  is  used  in  formulating  safety  properties.  The  appeal  of  the  p-calculus  lies  in  its  expressive 
powe^and  Us  ability  to  encode  many  other  temporal  logics  in  a  uniform  fashion  PT4I%  this  power  ^s  from  Us 
support  for  defining  recursive  propositions.  The  main  disadvantage  of  the  p-calculus  is  that  formulas  can  be  difficult 
SemetroX  *  to  the  complexity  that  can  result  from  mutually  recursive  definitions.  This  needn’t  be  a  prob  em 
in  practLrhoweverras  users  can  define  the  properties  of  interest  in  a  higher-level  notationlSvith  tools  then  handling 
flip  translation  into  the  u-calculus  for  the  purpose  of  automated  analysis.  . 

ConUnlg  »i.h  .he  Sample  of  the  faulty  half-duplex  linefon.  of  the  requirements 
that' there  are  no  deadlocks  in  the  system.  This  can  be  captured  using  the  formula  pX.Qtt  A [-]*  (where  represen  s 
the  set  of  all  labels)rwhich  is  true  of  a  state  s  provided  there  is  at  least  one  transition  out  of  state  s  and  the  formu  a 

In  the  rest  of  the  paper  we  will  show  how  to  modeirand  reason  aboutrsuch  reliability  issues. 

3  Probabilistic  Transition  Systems 

may  engage  in  with  its  environmentrwhile  the  latter  provides  information  about  the  states  the  system  m  y 

Definition  3.1  A  PLTS  L  is  a  tuple  (5,6,  Pi  J)rwhere 

•  ($,  s'  1  si  €)S  is  a  countable  set  of  states; 

•  6  C  S  x  Act  x  5  is  the  transition  relation; 

0  p  :  S  —*  (0,  l]rthe  transition  probability  distributionr satisfies:  5Z(il0,i')e«  -P(s>a»s )  e  ^ 

a  G  Act;  and 


0  J  l  S  — *  It ‘  id  me  luutiy*'-'''***''**  - 

Intuitivelyra  PLTS  r^ord,  the  opet.«ona,  behavio,  »f  l ZESti 

t  the  execution  eteps  enabled  in  < "eitiou  labeled  by 

is  that  when  the  environment  of  the  system  enables  ....  .  the  transition  (s.  a,  s')  is  selected 

the  action.  When  this  is  the  aS‘SP(s,a  s  )  .ept'sen  s  e  Pro  ,hat  the  conditions  on  P  ensure  that  if 

as  opposed  to  other  transdrous  labeled  by  o  emanatu*  ^  ^  ^  we  ^ite  s  -2.  s'  if  (a,a,p)  €  i- 
(s,  o,  s')  G  6  for  some  s  Tthen  E(J(O,*0e«  ('  *  ’  ^ediumrwe  could  specify  that  5%  of  all  data  packets  are  lost  by 

the s: = — -  -  -  be  ■ - K 


.  2Prop  is  the  interpretation  function. 


-69- 


dataS  =  Send  data 
data  =  Receive  data 

ack  =  Receive  Ack 
ackS  =  Send  Ack 

Figure  3:  A  probabilistic  characterization  of  faults  in  a  lossy  medium 


ia  2/3 

— "m 


Figure  4.  A  PLTSrits  unrolling  from  a  staterand  an  observation. 


the  fact  that  data  packets  are  traditionally  longer  and  thus  have  a  greater  chance  of  being  corrupted.  The  modified 
specification  is  given  in  Figure  3. 

Given  such  a  specification  we  might  wish  to  check  whether  it  satisfies  the  Mowing  requirement: 

It  k  always  true  that  the  probability  of  successfully  sending  a  data  packet  in  three  tries  is  greater  than 
99%  and  that  the  probability  of  successfully  sending  an  ack  packet  in  two  tries  is  greater  than  99.5%. 

To  answer  this  question  we  will  have  to  describe  a  measure  space  over  which  our  logical  specifications  are  in¬ 
terpreted.  To  that  endrwe  wish  to  view  a  (state  in  a)  PTLS  as  an  “experiment”  in  the  probabilistic  senserwith 
an  outcome  Tor  observation  representing  a  resolution  of  all  the  possible  probabilistic  choices  of  transitions  the 
system  might  experience  as  it  executes.  More  specificallyrgiven  a  state  in  the  PLTS  we  can  unroll  the  PLTS  into  an 
infinite  tree  rooted  at  this  state.  An  observation  would  then  be  obtained  from  this  tree  by  resolving  all  probabilistic 
choicesri.e.  by  removing  all  but  one  edge  for  any  given  action  from  each  node  in  the  tree.  Figure  4  presents  a  sample 
PLTSrits  unrolling  from  a  given  staterand  an  associated  observation. 

3.1  PLTSs  and  Measure  Spaces  of  Observations 

To  define  the  observation  trees  of  a  PLTS  we  introduce  partial  compvtaiionsTvrhkh  will  form  the  nodes  of  the  trees. 
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Definition  3.2  Let  L  =  (S,  6)  P,  J)  be  a  PUTS.  Then  a  sequence  of  the  form  Sq  A  si  *  •  •  sn  is  a  partial  computation 
of  L  if  n  >  0  and  for  all  0  <  i  <  nTsi  si+1. 


Note  that  any  s  E  S  is  a  partial  computation.  If  <r  =  so  A  •  •  •  2$  sn  is  a  partial  computation  then  we  define  fst(<r) 
to  be  so  and  Ist(cr)  to  be  sn.  We  also  use  (cr,cr'  £)Ci  to  refer  to  the  set  of  all  partial  computations  of  L  and  take 
C^(s)  =  {cr  E  Cl  |  fst(cr)  =  s}  for  s  E  5.  We  define  the  following  notations  for  partial  computations. 


Definition  3,3  Let  a  =  so  A  s\  •  •  •  £3.  sn 
(5, 5,  P,  J)rand  let  a  E  Ad . 


and  o’7  =  Sq  -i  sj  •  •  •  sjj,  be  partial  computations  of  PLTS  L  = 


1.  If  sn  — ►  Sq  then  a  -*  a'  is  the  partial  computation  sq  -4  si 


On  C  1  “1  / 

-+  $n  «o  52  ' 


a./  . 

‘  5n/. 


2.  o*'  is  a  prefix  of  cr  if  cr7  =  sq  Si 


Ci 


Si  for  some  i  <  n. 


We  also  introduce  the  following  terminology  for  sets  of  partial  computations. 


Definition  3.4  Let  L  =  (S,6,P,  J)  be  a  PLTSrand  let  C  C  Cl  be  a  set  of  computations. 

1.  C  is  prefix-closed  ifTfor  every  a  EC  and  a'  a  prefix  of  oTcr'  E  C. 


2.  C  is  deterministic  if  for  every  cr,  cr'  EC  with  cr  =  so  A  Si  •  •  •  A  sn  As- 
either  a  ^  o'  or  s  =  s'. 


and  cr'  =  so  Si  •  •  •  sn  A  s'  •  •  -T 


The  term  prefix-closed  is  standard!?  but  the  notion  of  determinacy  of  sets  of  partial  computations  deserves  some 
comment.  IntuitivelyFif  two  computations  in  a  deterministic  set  of  partial  computations  share  a  common  prefixr 
then  the  first  difference  they  can  exhibit  must  involve  transitions  labeled  by  different  actions;  they  cannot  involve 
different  transitions  with  the  same  action  label. 

We  can  now  define  the  deterministic  treesTor  d-treesTof  a  PLTS  L  as  follows. 


Definition  3.5  Let  L  =  (S,  5,  P,  I)  be  a  PLTS.  Then  0  £  T  C  Cl  is  a  d-tree  if  the  following  hold. 

1.  There  exists  an  s  E  S  such  that  T  C  Cx(s). 

2.  T  is  prefix-closed. 

3.  T  is  deterministic. 

If  C  is  a  d-tree  then  we  use  root(C)  to  refer  to  the  s  such  that  C  C  Cl(s)  and  edges(C)  to  refer  to  the  relation 
{(cr,  a,  cr7)  |  cr,  cr'  E  C  A  3s'  E  S.cr7  =  cr  A  s}. 

We  use  Ti  to  refer  to  all  the  d-trees  of  L  and  set  7i(s)  =  {T  E  Ti,  |  root(T)  =  s}.  We  call  T*  a  prefix  of  T  if 
T'CT  We  write  T  A  T'  if  {root(T)  A  cr7  |  a'  E  T'}  C  T;  intuitivelylT'  is  then  the  subtree  of  T  pointed  to  by  an 
a-labeled  edge.  A  d-tree  T  is  finite  if  \T\  <  00.  FinaUyTwe  say  that  a  d-tree  is  maximal  if  there  exists  no  d-tree  T' 
with  T  C  T'  and  use  Ml  and  Ml(s)  to  refer  to  the  set  of  all  maximal  d-trees  of  L  and  all  maximal  d-trees  of  L 
rooted  at  ^respectively. 

We  wish  to  view  the  maximal  deterministic  d-trees  of  a  PLTS  as  the  “outcomes”  of  the  PLTS  and  to  talk  about 
the  likelihoods  of  different  sets  of  outcomes.  In  order  to  do  thisIVe  define  a  probability  space  over  maximal  d-trees 
rooted  at  a  given  state  of  L .  The  construction  of  this  space  is  very  similar  in  spirit  to  the  standard  sequence  space 
construction  for  Markov  chains  [8]:  we  define  a  collection  of  “basic  cylindrical  sets”  of  maximal  trees  and  use  them 
to  build  a  probability  space  over  sets  of  maximal  trees.  The  technical  details  appear  below;  in  what  followsrfix 
L  =  (S,*,P,J). 

A  basic  cylindrical  subset  of  Ali(s)  contains  all  trees  sharing  a  given  finite  prefix. 

Definition  3.6  Let  s  €  Srand  let  T  €  7i(s)  be  finite.  Then  Bt  Q  Ml(s)  is  defined  as:  Bt  =  {  T  €  Ml  |  T  C  T'}. 
We  can  also  define  the  measure  of  a  basic  cylindrical  set  as  follows. 

Definition  3.7  Let  T  €  Ti(s)  be  finiteTand  let  By  be  the  associated  basic  cylindrical  set.  Then  the  measure T 
m(J3r)rof  Bt  is  given  by:  m {Bt)  =  H(<7,o,<r')e«<Js«(T)-P(lst(o’),  a,  Ist^)). 
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Intuitivelyrm(J5T)  represents  the  proportion  of  all  maximal  d-trees  emanating  from  the  root  of  B t  that  have  Bj  as 
a  prefix. 

For  any  given  state  s  in  L  we  can  form  the  associated  collection  of  basic  cylindrical  sets  By  consisting  of  sets  of 
the  form  By  for  finite  T  with  root(T)  =  $.  We  can  then  define  a  probability  space  (Af£(s),  Bs,ms)  as  follows. 

Definition  3.8  Let  sGS.  Then  B3  is  the  smallest  field  of  sets  containing  Bj  and  closed  with  respect  to  denumerable 
unions  and  complementation,  m*  :  Bs  — ►  [0, 1]  is  then  defined  inductively  as  follows. 

m  s(Br)  =  m(Bj) 

m,  (l>)  =  E  for  pairwise  disjoint  £,• 

»‘e/  »€/ 

m  ,{BC)  =  1-m  ,{B) 

It  is  easy  to  show  that  for  any  sF rrij  is  a  probability  measure  over  Bs.  Consequentlyr(A<i(s),B,J  m,)  is  indeed  a 
probability  space.  We  refer  to  a  set  M  C  Ml(s)  as  measurable  if  M  6  Bs . 

4  Syntax  of  GPL 

Generalized  Probabilistic  Logic  (GPL)  is  parameterized  with  respect  to  a  set  (X,Y  £)Var  of  propositional  variablesr 
a  set  (a,  b  G)Ad  of  actionsrand  a  set  (A  E)Prop  be  a  set  of  atomic  propositions.  The  syntax  of  GPL  may  then  be 
given  using  the  following  BNF-like  grammar Twhere  0  <  p  <  1. 

4>  A  |  -»j4  |  <f>i  A  <t>2  \  <f>i  V  02  I  &>pip  \  JE>P$ 

::=  0  |  X  |  0i  A  I  i>i  V  ^2  I  (a)V>  I  I  I 

The  operators  p  and  v  bind  variables  in  the  usual  senseT  and  one  may  define  the  standard  notions  of  free  and 
bound  variables.  AlsoTwe  refer  to  an  occurrence  of  a  bound  variable  X  in  a  formula  as  a  ^-occurrence  if  the  closest 
enclosing  binding  operator  for  X  is  p  and  as  a  ^-occurrence  otherwise.  GPL  formulas  are  required  to  satisfy  the 
following  additional  restrictions:  they  must  contain  no  free  variablesFand  no  sub-formula  of  the  form  pXsfr  ( vX .^) 
may  contain  a  free  ^-occurrence  (^-occurrence)  of  a  variable.1  In  what  follows  we  refer  to  formulas  generated  from 
nonterminal  <f>  etc.  as  state  formulas  and  those  generated  from  as  fuzzy  formulas ;  the  formulas  of  GPL  are  the 
state  formulas.  We  use  (0,$'  e)$  to  represent  the  set  of  all  state  formulas  and  (^,^;  €)^  for  the  set  of  all  fuzzy 
formulas.  In  the  remainder  of  the  paper  we  write  jIT'/X]  to  denote  the  the  simultaneous  substitution  of  Y  for  all 
free  occurrences  of  X  in  7.  We  also  note  that  although  the  logic  limits  the  application  of  -1  to  atomic  propositionsr 
this  does  not  restrict  the  expressiveness  of  the  logicras  we  indicate  later. 

The  next  subsection  defines  the  formal  semantics  of  GPLlTbut  the  intuitive  meanings  of  the  operators  may  be 
understood  as  follows.  Fuzzy  formulas  are  to  be  interpreted  as  specifying  sets  of  observations  of  PLTSsFwhich  are 
themselves  non-probabilistic  trees  as  discussed  above.  An  observation  is  in  the  set  corresponding  to  the  fuzzy  formula 
if  the  root  node  of  the  observation  satisfies  the  formula  interpreted  as  a  traditional  mu-calculus  formula:  so  (a)^ 
holds  of  an  observation  if  the  root  has  an  a-transition  leading  to  the  root  of  an  an  observation  satisfying  ^rwhile 
it  satisfies  [a]$  if  every  a-transition  leads  to  such  an  observation.  Conjunction  and  disjunction  have  their  usual 
interpretation.  pX,Tp  and  v  X.il>  are  fixpoint  operators  describing  the  “least”  and  “greatest”  solutionsrrespectivelyr 
to  the  “equation”  X  =  ip.  It  will  turn  out  that  any  state  in  a  given  PLTS  defines  a  probability  space  over  observations 
and  that  our  syntactic  restrictions  ensure  that  the  sets  of  observations  defined  by  any  fuzzy  formula  are  measurable 
in  a  precise  sense.  State  formulas  will  then  be  interpreted  with  respect  to  states  in  PLTSsrwith  a  state  satisfying  a 
formula  of  the  form  JE>pip  if  the  measure  of  observations  corresponding  to  the  state  is  at  least  p. 

4.1  Semantics  of  Fuzzy  Formulas 

In  the  remainder  of  this  section  we  define  the  semantics  of  GPL  formulas  with  respect  to  a  fixed  PLTS  L  =  (S,  6 ,  P,  I) 
by  giving  mutually  recursive  definitions  of  a  relation  S  x  $  and  a  function  ©x,  :  ^  The  former 


lIn  other  words,  formulas  must  be  alternation-free  in  the  sense  of  [3]. 
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indicates  when  a  state  satisfies  a  state  formularwhile  the  latter  returns  the  set  of  maximal  d-trees  satisfying  a  given 
fuzzy  formula.  In  this  subsection  we  present  ©x,;  the  next  subsection  then  considers  j=x,-  In  what  follows  we  fix 
L  =  {S,6,P,I). 

Our  intention  in  defining  QL(ip)  is  that  it  return  trees  thatrinterpreted  as  (non-probabilistic)  labeled  transition 
systemsTsatisfy  ip  interpreted  as  a  mu-calculus  formula.  To  this  endrwe  augment  ©x,  with  an  extra  environment 
parameter  e  :  Var  — *■  2Ml  that  is  used  to  interpret  free  variables.  The  formal  definition  of  ©x  is  the  following. 

Definition  4.1  The  function  0i  is  defined  inductively  as  follows. 

•  ©i(^)e  =  UJ^i^Afi(s) 


•  ©i(X)e  =  e(X) 

•  ©i((a)^)e  =  {T  1 3T'  :  T  V  A  V  €  ©i(V>)c} 

•  ©i([<#)e  =  {T  |  (T  T ')  =>  T  6  Ql  We} 

•  ©x.P’i  A  =  ©i(V'i)6  ©  ©z(lfo)e 

•  ©x,  W>i  V  fa)e  =  Qi.(ipi)e  U  0x(V>2)e 

•  ©iX/i^-VOe  =  U^0Mjrwhere  M0  =  0  and  M,+i  =  ©x(V')e[X  M,-]. 

•  Qi(yX.ip)e  =  n~0N,Twhere  /Vq  =  Afx,  and  iVf+i  =  0z(VOcP^  ^  -^i]. 

When  iP  has  no  free  variablesr©(V-)e  =  0tyOe'  for  any  environments  e,e'.  In  this  case  we  drop  the  environment  e 

and  write  ©x(V ’)•  ,  ,  .  ..  ,  „ 

Some  comments  about  this  definition  are  in  order.  FirstlyDt  is  straightforward  to  show  that  the  semantics  of  all 

the  operators  except  pi  and  v  are  those  that  would  be  obtained  by  interpreting  maximal  deterministic  trees  as  labeled 
transition  systems  and  fuzzy  formulas  as  mu-calculus  formulas  in  the  usual  style  [9].  SecondlyTbecause  d-trees  are 
deterministic  it  follows  that  if  T  €  ©x,«a)tf)  then  T  €  ©z([<#)-  Finallyrthe  definitions  we  have  given  for  pi  and 
v  differ  from  the  more  general  accounts  that  rely  on  the  Tarski-Knaster  fixpoint  theorem.  HoweverTbecause  of  the 
“alternation-free”  restriction  we  impose  on  our  logic  and  the  fact  that  d-trees  are  deterministicTthe  meanings  of 
piX.ip  and  vX.ip  are  still  least  and  greatest  fixpoints  in  the  usual  sense. 

We  close  this  section  by  remarking  on  an  important  property  of  Ql-  For  a  given  s  €  5  let  ©z,j(v)  ~  ©MV) n 
Ml(s)  be  the  maximal  d-trees  from  s  “satisfying”  ip.  We  have  the  following. 

Theorem  4.2  For  any  s  €  S  and  ip  G  '$f,  0l,j(VO  w  measurable. 


4.2  Semantics  of  State  Formulas 

We  now  define  the  semantics  of  state  formulas  by  defining  the  relation  l=x,- 
Definition  4.3  Let  L  =  ( S,6,P,I )  be  a  PLTS.  Then  \=L  is  defined  inductively  as  follows. 
•  sH,  A  iff  4  6  I(s). 


.  s\=eL  ->A  iff  A  &  I(s). 

•  s  A  <p2  iff  s  1=  <Pi  and  s  fa. 

•  s  \=*L  <p!  V  fa  iff  s  ^1  or  s  N  fa- 


♦  s  \=i  E>Pip  iff  m,(0£,,(VOe)  >  V- 

•  s  H  K>Pip  iff  m,(0i,,(^)c)  >P- 

An  atomic  proposition  is  satisfied  by  a  state  if  the  proposition  is  a  member  of  the  propositional  labeling  of  the 
state.  Conjunction  and  disjunction  are  interpreted  in  the  usual  mannerTwhile  a  state  satisfies  a  formula  &>PV 
the  measure  of  the  observations  of  ip  rooted  at  s  exceeds  prand  similarly  for  E>pip. 
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4.2.1  Properties  of  the  Semantics 

We  close  this  section  by  remarking  on  some  of  the  properties  of  GPL.  The  first  shows  that  the  modal  operators  for 
fuzzy  formulas  eiyoy  certain  distributivity  laws  with  respect  to  the  propositional  operators. 

Lemma  4.4  For  a  PITS  L,  fuzzy  formulas  fa  and  fa  and  a  G  Ad,  we  have: 

F  ©z,((a)(V'i  V  fa))  =  Qi({a)fa  V  (a)  fa) 

2.  0i([a](^i  V  fa))  =  0i([a]V>i  V  [a]fa) 

S.  QL((o)(fa  A  fa))  =  QL((a)ip i  A  (a)  fa) 

4 •  ©£.((a](V’i  A  fa))  =  ©z([atyi  A  [a]  fa) 

5.  ©x.([a]V’i  A  (a)  fa)  =  0L((a)(fa  A  fa)) 

That  [a]  distributes  over  V  and  (a)  over  A  is  due  to  the  determinacy  of  d-trees. 

Based  on  Theorem  4.2  and  the  definition  of  ©xTthe  next  lemma  also  holds. 

Lemma  4.5  Let  s  G  S,  a  G  Ad  and  ip, ip i,fa  G  \P.  Then  we  have  the  following. 

ma(6i(fa  Vfa))  =  m,(0i(V>i))  +  m,(0i(^2))  -  rns(0L(fa  A  ^2))  (1) 

m*(0z((a)VO)  =  -P(s,a,s,)*nv(0i(V>))  (2) 

(s,a,s')eS 

mJez([aU))  =  I  m'(Q*((aM)  if  (si  o,  s')  G  6  for  some  s' 

v  u  J  ”  l  1  otherwise  W 

Finallyral though  our  logic  only  allows  a  restricted  form  of  negationrwe  do  have  the  following. 

Lemma  4.6  Let  L  —  ( S,6,P ,1)  be  a  PLTS  with  s  G  S,  and  let  ip  and  <p  be  fuzzy  and  state  formulas,  respedively. 
Then  there  exist  formulas  neg(ip)  and  neg(^)  such  that: 

^L,s(neg(ip))  =  Ml(s)  -  Qi,,(ip)  and  s  neg(<£)  -  s  4>- 

Proof  1  Follows  from  the  duality  of  A/vr[a]/(a)rz//prand  K>p/R>i_p.  m 

5  Expressiveness  of  GPL 

In  this  section  we  will  compare  our  interpretation  of  GPL  with  a  similar  effort  by  Huth  and  Kwiatkowska  [7]r 
who  develop  a  notion  of  quantitative  model  checking  [7]  in  which  one  calculates  the  likelihood  with  which  a  system 
state  satisfies  a  formula.  The  basis  for  their  approach  lies  in  a  semantics  for  the  modal  mu-calculus  that  assigns 
“probabilities” IYather  than  truth  valuesrto. assertions  about  states  in  a  PLTS.  In  this  section  we  briefly  review  their 
approachroffer  a  criticism  of  itrand  show  how  GPL  provides  a  principled  means  of  remedying  the  criticism. 

The  syntax  of  their  logic  coincides  with  the  semantics  of  our  fuzzy  formulas  with  the  following  exceptions:  (1) 
they  allow  negation  (although  in  such  a  way  that  negations  can  be  eliminated  in  the  usual  manner);  (2)  the  only 
atomic  propositions  are  tt  (“true”)  and  ff  (“false”);  (3)  no  use  of  the  probabilistic  quantifiers  M>p  and  M>p  is  allowed. 
They  then  present  three  semantics  for  the  logic  that  differ  only  in  their  interpretation  of  conjunction.  Each  interprets 
formulas  as  functions  mapping  states  to  numbers  in  [0, 1];  formallyrgiven  PLTS  LV^iph  :  S  -*  [0, 1]  represents  the 
interpretation  of  formula  ip.  What  follows  presents  the  relevant  portions  of  these  semantics. 

I«UW  =  1 

[(£#]l(s)  =  X)  P(s>a>s')'WL(s') 

lfaAfa]L(s)  =  =  f([fah(s),[fa]L(s)) 
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The  meanings  of  the  other  boolean  and  modal  operators  may  be  obtained  using  dualities  (e.g.  Raffli  i)  -  1 
/ f/a\_1^,Ti)r while  the  meanings  of  fixed  points  may  be  obtained  using  the  usual  Tarski-Knaster  construction.  The 

semantics  of  A  contains  a  parameter  /;  [7]  provides  three  different  instantiations  of  /. 

1.  /(*,y)  =  min(*,y) 

2.  f(x,y)  =  x  •  y 

3.  /(*,  y)  =  max(x  +  y  -  1, 0) 

Each  unfortunately  has  Us  drawbacks.  The  first  two  fail  to  validate  some  expected  logical  equivalences;  for  example 
i  t>w»  rase  that  tt  is  equivalent  to  ipV->xp.  The  authors  refer  to  the  third  as  a  “fuzzjd  interpretation  and  indicate 

Hu  is  are  “ not 

“1GPltermils  a  similar  interpretation  to  be  attached  to  the  mu-cakulusltut  in  snch  a  way  that  exact  probabilities 
may  be  assigned  to  formulas.  Consider  the  function  given  by. 

One  can  show  that  this  interpretation  preserves  mnch  ot  the  semantics  of  Hath  and  i !“ ‘  f 

mas  4  5  and  4  6  show  that  this  definition  attaches  the  same  interpretations  to  the  modalities.  I 

expected  logical  equivalences  holdrand  that  this  interpretation  yields  a  probability  with  apreaser me^e-th 

interpretation.  Finallyrit  should  be  easy  to  observe  that  our  logic  coincides  with  probability  bisimulation  [10]  -  a 

property  not  true  of  Huth  and  Kwiatkowska’s  interpretation. 

6  Model  Checking 

a^T^eiy^ylateslte^ie^ure^HOTieverrUiU  two^ste^approa^^^uw^^^^W^^e^b^^^^^^^^^a 

dependency  graph  that  allo^us  SnUSyPthe  nodes  of  the  dependency  graph 

me  SwM*  palm  of  the  form  (s,  Fjrwhere  si.  a  state  of  and^  is  a  subset  form 

ip.  The  edges  that  connect  these  nodes  capture  the  depen  ency.  >,ri»Vlled  bv  (s  F  —  i<t>}  U  {$1,^2})* 

* = *  4  * ~{ “ 

*4  do“  n\rt  ss: 

.  ..  ,  ±  w  ±  in  fhU  raseTthe  dependency  graph  has  three  successors  to  t$,r J,  t  j 

- JiZms,  F  -  W  U  (M)rand  (s,  F  -  <«  U  «.,«)•  These  four  nodes  captme  Eqnatron  n. 

lemma  4.5rwhich  charaderites  the  measure  of  trees  satisfying  a  disjunction.  ..  d  (sf)  such 

We  now  come  to  the  hardest  case  in  the  construction  of  the  dependency  graph.  Consider  a  node  t  ,  > 

that  all  formula  in  F  are  of  the  formed  «  W-  1 ^ ^“e  ^  * 

(s  IdlMd  £  F  or  [aW  £  F}).  Let  n  be  the  node  (s,  Fjriet  An  -  40  |  t", I 
X„  stand  for  measure  denoted  by  node  n.  These  edges  capture  the  constraint: 

X„=  II  E  (F(s,  o,s')-X(...fj)) 
a£An  (n.a.^SsFO)^ 

perhaps  by  using  tools  such  as  MapleTwe  can  easily  check  whether  &>Pi>  holds  at  state  s0. 
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7  Concluding  Remarks 

We  have  presented  a  uniform  framework  for  defining  temporal  logics  on  reactive  probabilistic  transition  systems 
Our  approach  is  based  on  using  the  modal  mu-calculus  to  define  measurable  sets  of  observations  of  such  systems’ 
We  have  showed  that  our  logic  is  expressive  enough  to  encode  two  different  existing  temporal  logicsrand  we  have 

™  “  may  l°  KCtify  a"  in  a  thW-  A  modd-cheddns  procedure  for  the  logic 

An  important  issue  for  future  work  is  that  of  applying  our  logic  to  more  general  transition  systems  (for  examoler 
the  transition  systems  of  [14  and  establishing  its  relation  to  probabilistic  automata^.  Such  an  extendotTou W 

tP““ that  ”  *“1  lhe  ~  ~  lacking  "°ot 
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Abstract 

We  show  how  Deductive  Model  Checking,  a  method  that  combines  deductive  and  algorithmic  verifica¬ 
tion  of  temporal  properties  of  reactive  systems,  can  be  understood  as  interactively  specifying  a  finite-state 
extended  abstraction.  The  transformations  of  DMC  correspond  to  refinement  operations,  which  construct 
an  abstract  finite-state  system,  and  model  checking  operations,  which  check  that  it  satisfies  an  abstract 
temporal  property.  The  refinement  steps  make  the  overapproximated  abstract  transition  relation  smaller, 
and  the  underapproximated  one  larger.  They  also  add  fairness  contraints  to  the  abstract  system,  by  com¬ 
puting  abstract  bounds  on  the  enabling  conditions  of  fair  transitions,  and  eliminate  unfeasible  abstract 
loops  by  using  well-founded  orders. 


1  Introduction 

Methods  for  the  verification  of  temporal  properties  of  reactive  systems  have  traditionally  been  classified  as 
deductive  or  algorithmic.  Deductive  methods  apply  verification  rules,  which  reduce  the  validity  of  temporal 
properties  to  that  of  verification  conditions.  Algorithmic  methods,  also  known  as  model  checking,  prove 
temporal  properties  by  exhaustively  exploring  the  state-space  of  the  system. 

While  algorithmic  methods  are  automatic  and  can  produce  counterexamples  when  the  property  fails, 
they  are  usually  restricted  to  finite-state  systems,  or  specialized  classes  of  infinite-state  ones.  On  the  other 
hand,  deductive  methods  can  verify  general  infinite-state  systems,  but  require  user  interaction  and  do  not 
produce  counterexamples. 

Deductive-algorithmic  methods  combine  the  two  approaches.  Since  the  problem  of  verifying  general 
infinite-state  systems  is  undecidable,  they  cannot  be  guaranteed  to  succeed  or  produce  counterexamples; 
however,  they  may  facilitate  the  verification  task  by  allowing  automatic  methods  to  perform  most  of  the 
combinatorial  exploration,  letting  the  user  focus  on  higher-level  aspects  of  the  proof. 

Abstraction  presents  a  general  approach  to  the  combination  of  deductive  and  algorithmic  methods:  in¬ 
stead  of  proving  properties  of  a  given  concrete  system  S,  a  simpler  abstract  system  SA  is  constructed,  which 
can  be  model  checked.  The  correctness  of  the  abstraction  is  justified  using  deductive  means,  and  guarantees 
that  if  a  property  holds  for  SA,  then  a  corresponding  property  holds  for  S.  However,  the  converse  is  often 
not  the  case:  if  a  property  fails  for  SA,  it  may  or  may  not  hold  for  S.  The  abstraction  must  then  be  refined 
until  the  property  can  be  proved  or  disproved. 

In  this  paper,  we  describe  how  the  deductive-algorithmic  method  of  Deductive  Model  Checking  (DMC) 
(15, 14]  does  precisely  this:  it  interactively  constructs  and  refines  an  abstraction  that  can  be  model  checked. 

As  we  will  see,  DMC  constructs  the  abstract  system  in  a  top-down,  hierarchical  manner,  interleaving  the 
model  checking  and  the  refinement  operations.  This  can  lead  to  space  and  tune  savings,  since  not  even  the 
full  abstract  state-space  needs  to  be  explored. 
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2  Preliminaries 

2.1  Concrete  Representation:  Fair  Transition  Systems 

Fair  transition  systems  [13]  are  a  convenient  formalism  for  describing  reactive  systems.  The  representation 
relies  on  an  assertion  language  to  represent  sets  of  states,  usually  based  on  first-order  logic.  A  state  of  a 
fair  transition  system  is  a  type-consistent  interpretation  of  all  its  system  variables  V.  The  set  of  all  states  is 
called  the  state  space,  written  E.  An  assertion  is  a  first-order  formula  whose  free  variables  are  a  subset  of 

V;  it  represents  the  set  of  states  that  satisfy  it; 

Definition  2.1  (Fair  Transition  System  (FTS))  A  fair  transition  system  S  :  (V,  0,  T,  J,  C )  is  given  by 
a  set  of  system  variables  V ,  an  initial  condition  0,  expressed  as  an  assertion  over  V,  a  set  of  transitions  T, 
relations  on  states,  represented  by  assertions  p  over  V  and  V',  where  V1  denotes  the  values  of  the  variables 
in  the  next  state,  a  set  of  just  transitions  J  C  T,  and  a  set  of  compassionate  transitions  C  C  T. 

An  infinite  sequence  of  states  a  :  s0,su...  is  called  a  computation  of  S  if  (1)  s0  satisfies  the  initial 
condition,  written  so  t=  0,  (2)  for  every  j  >  0,  there  exists  a  transition  r  €  T  such  that  {sj,sj+i)  t=pT, 

(3)  it  is  not  the  case  that  a  just  transition  is  continuously  enabled  beyond  some  point,  but  never  taken,  and 

(4)  every  compassionate  transition  that  is  infinitely  often  enabled  is  infinitely  often  taken,  where  we  say  that 
a  transition  t  is  enabled  on  a  state  s  if  there  exists  a  state  s1  such  that  (s,  s')  C  t,  and  a  transition  t  is 
taken  at  position  j  if  (sj,  sj+i)  C  r. 

2.2  Specification:  Formula  Automata 

A  temporal  property  can  be  specified  by  a  formula  automaton,  or  w-automaton.  Several  types  of  finite-state 
w-automata  exist;  here  we  will  use  the  type  known  as  Muller  automaton. 

Definition  2.2  (Muller  automaton)  A  Muller  automaton  M  :  (N,No,E,p,F)  over  a  domain  E  is  a 
directed  graph,  consisting  of  a  finite  set  of  nodes  N,  a  subset,  N0,  of  which  are  initial,  a  set  of  edges  E,  a 
node  labeling  function  p  that  assigns  to  each  node  a  subset  of  E  and  an  acceptance  condition  T  C  2N  given 
by  a  set  of  subsets  of  nodes. 

An  infinite,  sequence  of  states  cr  :  s0 ,  si , . . .  is  a  run  of  an  automaton  M  if  there  exists  a  path  it  :  no ,  m , . . . 
through  M  such  that  n0  C  N0,  and  for  every  j  >  0,  sj  €  p(nj).  A  run  is  a  model  of  the  automaton  if  it 
is  accepted  by  the  acceptance  condition,  that  is,  there  exists  a  path  x  such  that  infix)  €  T,  where  infix) 
is  the  set  of  nodes  that  appears  infinitely  often  in  x.  Clearly  the  nodes  that  appear  infinitely  often  have  to 
be  a  strongly  connected  subgraph  (SCS)  of  the  automaton.  Hence,  only  SCS’s  have  to  be  considered  in  the 
acceptance  condition. 

2.3  Ranking  Functions 

Ranking  functions  are  used  to  justify  that  loops  cannot  be  traversed  infinitely  many  times. 

Definition  2.3  (Ranking  functions)  A  binary  relation  >-  over  a  domain  V  is  a  subset  ofiDxV,  where  we 
write  si  y  $2  iff  («i,  $2)  G  >-  .  ■  A  binary  relation  y  is  well-founded  over  V  if  there  are  no  infinite  sequences 
of  elements  ei, . . . ,  en, . . .  in  D  such  that  e\  y  e2  y  ...  y  eny  ...  A  ranking  function  <5  is  a  mapping  from 
system  states  into  a  well-founded  domain  [V,  y).  We  write  xyy  iff  x  y  y  or  x  —  y . 

2.4  Abstraction 

We  use  a  standard  instance  of  abstraction  [7],  where  the  abstract  system  is  given  in  terms  of  an  abstract 
domain  E^,  usually  a  complete  lattice.  For  each  abstract  state  in  E^,  a  concretization  function  7  gives  the 
set  of  concrete  states  7(a)  that  a  represents.  An  abstraction  function  a  gives,  for  a  set  of  concrete  states,  the 
smallest  abstract  state  that  includes  it.  The  abstract  domain  we  use  is  particularly  simple,  but  has  proved 
useful  for  generating  and  proving  invariants  [9, 1]  and  general  temporal  properties  [6]. 
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Definition  2.4  (Assertion-based  abstraction)  Given  a  finite  set  of  assertions  B,  the  assertion-based 
abstract  domain  with  basis  B  has  the  complete  boolean  algebra  BA(B)  (using  its  abstract 

domain  E*,  where  7(/)  *=  {s  G  E  |  s  b  /},  and  a(S)  d=  {s^  G  BA{B)  1 5  C  7(s^)}. 

That  is,  the  concretization  7(/)  of  an  assertion'/  is  simply  the  set  of  concrete  states  that  satisfies  it. 
The  abstraction  a{S)  of  a  set  of  states  S  is  the  smallest  point  in  the  abstract  lattice  whose  concretization 
includes  all  the  elements  of  5. 

If  sA  is  an  abstract  assertion  (or,  equivalently,  an  abstract  state),  then  y{sA)  is  characterized  by  the 
concrete  assertion  obtained  from  sA  by  replacing  Aa,  VA  and  -v4  by  A,  V  and  The  boolean  variables 
in  sA,  which  are  elements  of  B,  appear  as  corresponding  subformulas  in  7(s^).  That  is,  7  is  a  boolean 
homomorphism  between  the  two  assertion  languages. 

If  2^  is  a  correct  abstraction  of  S  and  we  can  establish  that  E ^  t=  <PA,  then  we  will  know  that  E  H  7(p), 
where  7(v>)  is  obtained  by  replacing  each  assertion  in  <pA  by  its  concretization.  These  abstractions  are  weakly 
preserving:  if  E^  does  not  satisfy  <pA,  we  cannot  conclude  that  E  does  not  satisfy  <p. 

For  an  abstract  binary  relation  ta ,  we  define 

7(t*4)  =f  {(si,s2)  |  si  €  7(ai)  A  $2  G  7(a2)  for  some  (ai,a2)  €  rA}  . 

2.5  Abstract  Representation:  Extended  Finite-State  Abstractions 
Following  [16],  our  representation  for  abstract  systems  has  the  following  components: 

1.  An  over-approximated  initial  condition  0^,  where  ©  C  7(0^). 

2.  A  set  of  abstract  transitions  {rf4, . . .  ,ta)  that  over-approximate  the  concrete  ones,  in  the  sense  that 
Ti  c  -/(r-4).  These  are  known  as  the  “free,"  “liberal,”  or  “33”  abstract  transition  relations  [5,  8],  and 
are  used  to  prove  universal  temporal  properties  for  the  abstract  system  that  can  then  be  transferred 
to  the  concrete  one. 

3.  A  set  of  constrained  abstract  transition  relations  {^v^,  •  •  • ,  ^vBn}  >  where  rv3(ai ,  ®2)  holds  if  for  all 
si  G  7(ai)  there  exists  s2  G  7(a2)  such  that  t($i,s2)  holds.  These  are  also  known  as  the  “conservative”  ' 
or  “V3”  abstract  transition  relations,  and  are  used  to  prove  existential  temporal  properties. 

4.  A  fairness  table  that  includes,  for  each  fair  transition  r-4,  an  abstract  lower  bound  enabled~{r )  on  the 
enabling  condition  of  rA,  that  is, 

^{enabled- {ri))  C  enabled  {ri)  . 

5.  A  termination  table,  which  relates  well-foundedness  of  relations  at  the  concrete  level  with  relations 
over  the  abstract  system.  Each  row  of  the  table  contains: 

(a)  A  pair  of  ranking  functions  (<Mj)r  over  the  concrete  set  of  variables  V,  over  a  well-founded 
domain  Vr. 

(b)  A  precondition  prer  and  a  postcondition  postr,  which  are  abstract  assertions,  describing  sets  of 
abstract  states. 

(c)  A  result,  which  is  either  -<  or  ;<• 

The  verification  conditions  that  justify  the  correctness  of  a  termination  table  row  r  with  result  -< 
(resp.  •<)  are: 

7(?re^)(V)  Arr(V,V')  A7(posf^)(V')  ->•  <5r,i(VH  (resp.  ^)«5r,2(V') 

and 

(7(pre^)(V)  V  7(posf^)(V))  ->  (5r,i(V)  G  TV  A  Sr>2{V)  6  VT)  . 

That  is,  whenever  rr  is  taken  from  a  state  that  preA  represents,  to  reach  a  state  that  postA  represents, 
the  well-founded  order  given  by  {5r,u6r,2)  decreases  (x)  or  is  not  increased  {<). 
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3  Deductive  Model  Checking 

Deductive  model  checkin?  (dmc)  [15]  is  a  method  for  the  interactive  model  checking  of  possibly  infinite-state 
systems,  generalizing  the  classic  explicit-state  model  checking  procedure  for  LTL  [13].  The  procedure  itself 

15  T S ^  [I5'c41'  “  heK  TO  f°OT  “  «“**  *»«*■  to  the  ibjtractta  poS  rf 

To  verify  that  a  system  S  satisfies  a  temporal  specification  ip,  the  classical  procedure  checks  whether  the 

* ehamor?raph>  thffc  1S> the  Product  graph  of  the  automaton  representing  -up  and  the  transition  graph 
admits  any  counterexample  computations.  The  DMC  procedure  starts  with  a  skeleton  of  the  behavior ^raph 
and  progressively  refines  and  transforms  this  graph  until  a  counterexample  is  found  or  it  is  demonstrated 
that  such  a  counterexample  cannot  exist.  This  graph  is  called  the  falsification  diagram  for  <S  and  As 
their  name  suggests  falsification  diagrams  are  dual  to  Verification  Diagrams  [12,  4].  Instead  of  showing  that 
every  computation  of  5  can  stay  within  an  accepting  SCS,  as  in  the  verification  diagram  case,  we  now^how 
that  every  computation  of  S  in  the  diagram,  if  any,  must  end  in  a  non-accepting  SCS. 

3’i  (Fabifi5ati°*  diagram)  Given  an  FTS  S  and  a  temporal  property  <p,  a  falsification  dia¬ 
gram  for  S  and  ip  ts  a  directed  graph  Q  :  {N,N0,E,p, t],k,F)  consisting  of  an  automaton  (N,N0,E,u,7) 
over  the  state  space  of  S,  with  two  additional  edge  labeling  functions,  tj  and  k,  which  both  label  edges  with 
subsets  ofT,  the  set  of  transitions  of  S. 

An  infinite  sequence  of  states  a  is  a  model  of  a  falsification  diagram  Q  :  {N,N0,E,u,t>,k,T)  if  it  is  a 
model  of  the  underlying  automaton  of  Q\  the  underlying  automaton  of  Q  is  (N,N0tE',u,E)  where  E'  C  E 
only  includes  those  edges  e  such  that  77(e)  ^  0.  An  infinite  sequence  of  states  is  a  constrained  model  of  a 
falsification  diagram  Q  if  it  is  a  model  of  the  constrained  underlying  automaton  of  Q,  where  the  constrained 
underlying  automaton  is  {N,N0,E"  ,p,T),  with  E"  C  E  the  set  of  edges  e  such  that  *(e)  ^  0.  We  write 
£(£)  to  denote  the  set  of  all  models  of  Q,  and  Cc(Q)  to  denote  the  set  of  constrained  models  of  Q. 

Figure  1  shows  an  outline  of  the  Deductive  Model  Checking  (dmc)  procedure.  The  procedure  repeatedly 
applies  one  of  a  set  of  transformations  to  the  falsification  diagram,  until  a  counterexample  computation  is 
found  or  it  is  clear  that  no  such  computation  can  exist.  At  any  given  point,  the  models  of  the  falsification 
diagram  represents  a  superset  of  all  the  computations  of  the  system  that  may  possibly  violate  the  temporal 
property,  and  the  constrained  models  are  a  subset  of  the  computations  that  do  violate  the  temporal  property. 


3.1  DMC  as  Abstraction  Refinement 

By  abstraction  refinement,  we  mean  the  process  of  improving  the  approximations  represented  by  an  abstract 
system.  This  includes  making  33  transitions  smaller  and  V3  ones  larger,  while  retaining  the  soundness  of  the 
approximation.  Refinement  also  includes  obtaining  better  bounds  on  enabling  conditions  and  adding  new 
well-founded  orders. 

Deductive  Model  Checking  can  be  understood  as  the  process  of  refining  an  abstraction  of  S,  while 
simultaneously  model  checking  it.  The  dmc  transformations  may  be  classified  into  two  groups:  the  first 

performs  model  checking  tasks,  while  the  second  performs  abstraction  refinement,  justified  by  verification 
conditions. 

Model  checking  a  falsification  diagram  consists  of  checking  whether  the  diagram  embeds  any  abstract 
models.  Formally,  given  a  falsification  diagram  Q,  an  infinite  sequence  of  states  is  an  abstract  model  of  Q  if  it 
is  a  model  of  the  underlying  automaton  of  Q  over  the  abstract  statespace  defined  by  the  atomic  assertions  in 

the  node  labeling.  The  set  of  all  abstract  models  is  written  £A(G).  Abstract  constrained  models  are  defined 
similarly. 

Note  that  for  every  (concrete)  model  of  Q  there  exists  an  abstract  model,  but  not  necessarily  vice  versa, 
since  nodes  may  be  labeled  with  unsatisfiable  assertions  other  than  false,  eliminating  sequences  of  concrete 
states  passing  through  these  nodes,  but  not  the  corresponding  abstract  ones.  On  the  other  hand,  the 
verification  conditions  associated  with  the  constrained  transition  ensure  that  any  target  node  of  an  edge 
labeled  by  a  constrained  transition  is  satisfiable,  and  thus  for  every  abstract  constrained  model  there  exists 
a  corresponding  concrete  one. 

After  each  refinement  step  we  have  three  mutually  exclusive  possibilities: 
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System  S  Temporal  Property  <p 


Figure  1:  Outline  of  Deductive  Model  Checking  (DMC) 


1.  CA(G)  =  0.  The  abstract  system  can  be  successfully  model  checked,  that  is,  SA  t=  <pA,  where  i{<pA)  in 
this  case  is  equivalent  to  tp.  Since  SA  is  a  correct  abstraction  of  S,  this  means  that  S  ip. 

2.  CA(G)  ^  0-  The  abstract  model  checker  can  find,  in  the  constrained  V3  abstract  relation  for  SA,  a 
counterexample  to  <p,  in  which  case  we  know  that  S  <p. 

3.  None  of  the  above.  The  abstract  model  checker  can  only  determine  that  SA  $  ipA,  finding  an  abstract 
counterexample,  but  cannot  determine  if  a  concrete  counterexample  exists.  Thus,  it  may  be  the  case 
that  S  b  (p,  but  SA  is  too  abstract  to  prove  or  disprove  it.  In  this  case,  the  abstraction  must  be  refined. 


A  model  checker  specially  tailored  for  this  task  is  presented  in  [16].  A  practical  consequence  is  that  a 
procedure  similar  to  DMC  can  be  implemented  using  a  theorem  prover  and  a  model  checker  as  black  boxes, 
provided  that  the  model  checker  gives  feedback  sufficient  to  select  the  next  refinement  transformation,  n 
DMC  succeeds,  then  a  corresponding  abstraction  exists  that  can  be  model  checked. 

We  should  note  that  DMC  provides  an  interactive,  goal-oriented  way  of  finding  a  suitable  abstraction. 
Furthermore,  it  can  selectively  refine  only  those  transitions  and  abstract  states  that  are  relevant  to  the 
property  being  proven.  Thus,  it  can  offer  significant  savings  even  for  the  finite-state  case.  The  abstraction 
is  computed  “on-the-fly ,”  so  that  not  even  the  entire  abstract  state-space  has  to  be  expanded. 

The  initial  abstraction:  The  initial  falsification  diagram  is  the  product  of  the  ~«p  automaton  and  the 
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abstract  system 


si  :  ({£>1  :  true*} ,  6  :buT)  , 

where  each  concrete  transition  n  is  approximated  by  rt*  :  true *  This  is  the  coarsest  abstraction  of  S,  with 
basis  B  .  :  true  }  and  only  tautological  (generally  valid)  temporal  properties  will  hold  for  it.  The  initial 

V3-approximations  are  false*. 

In  dmo,  edges  in  the  product  graph  are  labeled  by  sets  of  transitions.  Initially,  every  edge  is  labeled  by 
the  set  of  all  transitions.  J 


3.1.1  Model  Checking 

•  (model  checking):  The  model  checker  checks  whether  £*{g)  is  empty,  in  which' case  the  property  is 
-  proven,  or  whether  Cc  ( Q )  is  nonempty,  in  which  case  a  counterexample  has  been  demonstrated. 

Note  that  in  the  abstraction  framework,  the  only  unsatisfiable  nodes  are  those  that  are  propositionally 
unsatisfiable.  Li  dmc,  the  assertions  from  the  automaton  nodes  and  the  states  are  combined  and 
simplified.  This  corresponds  to  using  theorem  proving  to  decide  relationships  between  the  elements  of 
the  basis,  ruling  out  unsatisfiable  combinations. 

3.1.2  Refinement:  More  Specific  Transitions 

We  now  consider  two  ways  in  which  an  abstraction  can  be  refried.  First,  more  information  can  be  obtained 
about  particular  transitions  by  proving  verification  conditions  that  had  not  been  considered  previously,  given 
the  fixed  basis  of  the  atomic  assertions  that  appear  in  the  node  labeling.  In  the  second,  new  assertions  are 
added  to  the  basis,  dmc  provides  transformations  analogous  to  each  of  these: 

DMC  uses  edge  labels  to  keep  track  of  which  transitions  could  be  taken  at  an  edge.  Transitions  are 
removed  from  a  label  when  we  show  that  they  cannot  be  taken  at  that  edge: 

(remove  edge  label):  If  an  edge  from  m  to  n2  is  labeled  with  a  transition  r,  and  the  assertion 

M«i)(V)Ap(n2)(V')Ar(V,V') 
is  unsatisfiable,  remove  r  from  the  edge  label. 

This  is  equivalent  to  the  elimination  method  of  [1],  and  has  the  effect  of  conjoining  p(nx)  ->*  Vy  (n2)  to  the 
transition  relation  of  r*.  However,  in  dmc  the  refinement  is  local  to  a  given  edge:  the  transformation  does 
not  affect  other  edges  where  r  appears.  We  can  optimize  DMC  by  sharing  the  new  information  learned  about 
r  throughout  the  falsification  diagram.  This  has  the  effect  of  caching  the  proved  verification  conditions, 
reusing  them  whenever  possible. 

3.1.3  Refinement:  Finer  Abstract  Domain 

The  second  way  to  refine  an  abstract  system  is  to  choose  a  finer  abstract  domain,  by  introducing  new  basis 
elements.  Node  splitting  transformations  can  be  understood  as  doing  precisely  this: 

•  (binary  split):  Replace  a  node  n  by  the  two  nodes  nj  and  n2,  labeled  by 

H(ni)  :  fi(n)  Ax  and  p(n2) :  p(n)  A -.*)  . 

•  (n-ary  split):  Replace  a  node  n  by  the  nodes  m, . .  .Uj+i,  labeled  by 


M»i) 

p(n)  Api 

/*(»/) 

p(n)  A  pj 

M(nJ+ 1) 

fi(n)  A  ->(pi  V ...  V  pj) 

Removing  transitions  from  edges  after  a  split  is  equivalent  to  refining  abstract  transitions  under  a  new 
extended  basis.  As  described  in  [16],  computing  the  abstraction  that  results  from  adding  new  basis  elements 
or  test  points  can  be  done  without  repeating  the  previous  work. 
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3.2  DMC,  Fairness  and  Well-founded  Orders 

In  DMC  terminology,  a  transition  r  is  fully  enabled  at  a  node  n  if  /i(n)  C  enabled  (t).  We  know  that  a 
transition  cannot  be  taken  at  an  SCS  S  if  it  has  been  removed  from  all  the  77  edge  labels  in  S.  An  SCS  is 
then  Considered  unfair  if  some  just  (resp.  compassionate)  transition  is  fully  enabled  at  all  (resp.  some)  nodes 
in  5  and  is  missing  from  all  the  edges  in  S. 

DMC  renders  SCS’s  unaccepting  according  to  the  following  criteria: 

•  They  are  unfair  with  respect  to  some  transition  r,  in  the  sense  that  no  run  can  stay  in  the  SCS  without 
being  unfair  towards  r. 

•  They  are  well-founded,  that  is  they  have  an  edge  that  cannot  be  traversed  infinitely  many  times. 

Deductive  Model  Checking  assigns  ranking  functions  to  the  nodes  of  an  SCS,  to  show  that  a  computation 
cannot  forever  reside  within  the  SCS,  traversing  all  its  edges  and  visiting  all  its  nodes: 

Definition  3.2  (Terminating  edge)  An  edge  et  in  an  SCS  S  :  {ni, . . .  ,n*}  is  terminating  if  there  are 
ranking  functions  (5i, . .  .,£<;}  mapping  states  into  a  well-founded  domain  V  such  that: 

1.  for  every  edge  e  :  (711,712)  in  S  and  every  r  6  e 

p{ni)  At  A  p'fa)  <5i(V)  >;  ^(V') 

and 

2.  for  every  t  6  et, 

71(711)  At  A  p'{n2)  ->  <Ji(V)  >-  ^(V')  . 

We  say  that  an  SCS  S  for  which  a  tail (S) -computation,  that  is,  a  computation  that  eventually  ends  up  in 
the  SCS  S,  cannot  exist  is  terminating.  The  DMC  procedure  proves  the  termination  of  SCS’s  by  identifying 
terminating  edges.  Clearly,  if  et  is  terminating  in  5,  then  no  tail (S)-computation  can  traverse  et  infinitely 
many  times.  Such  edges  are.  removed  from  consideration,  yielding  smaller  SCS’s,  until  all  accepting  SCS’s 
can  be  shown  to  be  unfair,  unreachable  or  well-founded. 

In  some  cases,  the  ranking  function  for  a  node  depends  on  the  route  taken  to  reach  that  node.  An  unfolding 
transformation  makes  copies  of  SCS  nodes  and  allows  proving  that  an  SCS  cannot  support  a  computation 
even  when  suitable  ranking  functions  cannot  be  found  for  the  original  SCS.  With  this  machinery  in  place, 
DMC  is  relatively  complete,  as  proved  in  [15,  14].  As  usual,  this  assumes  that  the  assertion  language  is 
expressive  enough  and  that  a  complete  proof  procedure  for  the  required  verification  conditions  is  available. 

Concretization:  DMC  does  not  require  an  explicit  concretization  step,  since  the  assertions  in  -up  are  built 
into  the  initial  falsification  diagram.  Thus,  the  abstract  property  <pA  corresponds  exactly  to  the  original 
concrete  ip,  that  is,  7 (ipA)  =  tp. 

3.3  Counterexamples  in  DMC 

So  far,  we  have  only  used  the  (standard)  33-approximation.  Deductive  Model  Checking  can  also  be  used 
to  find  counterexamples,  by  collecting  additional  information  that  corresponds  to  the  generation  of  an  ab¬ 
straction  that  also  preserves  existential  properties.  This  is  done  by  adding  transitions  to  the  edgelabeling 
function  k,  which  corresponds  to  adding  new  edges  tp  the  constrained  (V3)  transition  relation. 

•  (addition  of  transition  in  DMC) .  Given  an  edge  e  =  (711,712)  ,  add  r  to  /t(e)  if  the  following  formula 
is  valid: 

W.(M(ni)  ->  3V'.(7-(V,VW(n2)))  . 

This  adds  71(71  1)  AA  7/ (712)  as  a  disjunct  to  7^3 .  The  set  of  transitions  contained  in  the  k  labeling  function 
in  a  falsification  diagram  describes  the  corresponding  7^3  abstract  transitions. 

Dually  to  the  “fully  enabled”  requirement  on  fair  transitions  for  standard  DMC,  the  existence  of  coun¬ 
terexamples  requires  that  fair  transitions  that  are  not  taken  be  fully  disabled  at  the  given  nodes,  that  is, 
71(11)  C  ->enabled(T).  We  can  then  define: 
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Definition  3.3  (Fully  fair)  A  transition  is  fully  taken  at  an  SCS  if  it  is  contained  in  the  k  of  an  edge  in 
the  SCS. An  SCS  S  is  fully  just  (resp.  fully  compassionate,)  if  every  just  (resp.  compassionate)  transition  is 
either  fully  taken  in  S  or  fully  disabled  at  some  node  (resp,  all  nodes)  in  S. 

A  counterexample  exists  if  there  is  a  reachable,  accepting,  fully  fair  SCS  S  in  the  underlying  constrained 
automaton;  a  toii(5)-computation  will  not  violate  any  fairness  requirements.  Note  that  all  the  assertions 
in  the  respective  nodes  should  be  satisfiable.  This  is  the  case  if  the  initial  condition  is  satisfiable  and  the 
V3-approximation  is  sound. 


4  Related  Work 

The  possibility  diagrams  of  [11]  and  the  non-Zenoness  diagrams  of  [14,  3]  are  verification  diagrams  that  also 
specify  a  V3  transition  relation,  allowing  existential  properties  to  be  proved.  Such  diagrams  can  describe  V3 
and  33  abstract  relations  in  a  common  diagrammatic  form. 

An  important  issue  in  practice  is  the  strength  of  the  validity  checker  and  theorem  proving  available,  and 
how  well  they  handle  first-order  quantifiers.  Decision  procedures,  integrated  with  first-order  logic,  can  help 
with  this  task  [2]. 

Other  top-down  methods  for  model  checking  infinite-state  systems  have  been  proposed,  which  are  related 
to  DMC;  see  [16]  for  a  survey  of  some  of  these. 
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Abstract 


Technology  transfer  from  academic  research  to  industrial  practice  is  hampered  by  social,  political  and  economic  Droblems 
more  that  by  technical  issues.  This  paper  describes  one  instance  of  successful  technology  transfer  based  on  a  speciabDuroose 
ZTZZ  associated  translation  tool  tailored  to  the  customer’s  needs.  The  key  lesson  to  be  lemS  from 

R>m,alb™  “  b'  If  they  ere  represented 

It  is  suggested  that  the  model  of  special-purpose,  domain-specific  languages  and  their  translators  are  an  important  vehicle  tn 

KSS  e  C6d  teZn°^  r°  pract!ce;. This  aPProach  enables  doma5n  experts  to  solve  problem  usln?f3iTer^toK 
tv.o  rhbL  •  ?n^erS  0fr^  ^cipjines  to  utilize  computers  without  becoming  software  engineers.  In  doing  so  we  not  only  mitieate 
the  chronic  shortage  of  qualified  software  personnel  but  also  simplify  the  problem  of  requirements  analysis  and  specification^ 

Keywords:  Domain-specific  languages;  Code  Synthesis;  Technology  Transfer 

1.  THE  PROBLEM 


The  ultimate  purpose  of  software  engineering  and  computer  science  is  to  produce  better,  cheaper  software  In  this 
context  software  refers  to  a  running  system.  The  production  of  high-level  source  code  is  a  possible  but  not  necessary 
intermediate  step.  Better  encompasses  all  qualitative  aspects  such  as  correctness,  efficiency  and  so  on.  Cheaper  refers 
to  the  overall  cost  of  a  software  system  including  production,  deployment,  and  maintenance. 

Theoretical  problems  such  as  models  for  component  composition,  better  theorem  proving  technology,  formalized 
requirements  analysis  and  the  like,  are  important  elements  of  a  solution.  The  question  is  how  best  to  make  them 
practical. 

Software  engineers,  desperate  for  automation,  often  create  ad-hoc  solutions  without  any  formal  basis.  For  example, 
the  need  to  structure  and  organize  complex  software  systems  has  lead  to  the  creation  and  success  of  UML.  The  question 
is  how  best  to  put  these  tools  on  a  rigorous  formal  basis. 

TJere  is. 511  imPressive  list  of  projects  that  use  formal  methods  [1].  Yet  most  of  the  examples  cited  required  extensive 
hand-holding  by  researchers  and  do  not  represent  successful  theory  in  wide-spread  use.  Examples  of  formal  methods 
USe  3X6  m°re  modest  and  include  grammars,  supported  by  parser  generators,  and  finite  state  machines  [7]. 

Why  does  computer  science  not  have  a  larger  impact  on  software  engineering  practices?  Clearly,  there  are  many 
theories  that  should  be  valuable  and  useful  in  practice  and  there  are  many  practical  tools  that 

There  is  a  big  communication  gap  between  theoreticians  and  practitioners.  For  the  theoretician  programs  are 
mathematical  objects  that  never  fail  if  we  can  just  get  their  specification  right  and  verify  the  code.  For  the  practitioner 
formal  methods  use  obscure  notation,  deal  with  toys  examples,  and  will  never  scale.  Software  engineers  are  faced  with 
daunting  management,  version  control,  and  similar  problems  and  must  constantly  make  engineering  tradeoffs  to  meet 
tight  deadlines  and  market  windows  -  computer  scientists  know  little  of  that.  Computer  scientists  create  wonderful 
theories,  concepts  and  abstractions  -  software  engineers  understand  little  of  that. 

Transitioning  science  to  engineering  is  not  just  a  technical  problem  but  is  mainly  an  educational,  social,  managerial 
problem. 

Educational:  Software  engineers  could  make  use  of  many  theoretical  results  if  they  knew  how  to  do  so.  But  we 
don  t  speak  the  same  language.  The  presentation  of  research  results  is  geared  toward  peer  review  not  towards 
technology  transition. 

Social:  Software  engineers  are  reluctant  to  take  outside  advice.  After  all  they  manage  to  build  complex  systems. 

Who  likes  to  be  told  that  some  of  his  expertise  can  be  replaced  by  a  program? 

Managerial:  Processes  and  procedures  for  software  construction  have  evolved  over  many  years  and  are  firmly  en¬ 
trenched  in  organizations.  Any  change  will  be  perceived  as  risky  and  is  likely  rejected. 

This  paper  describes  an  example  of  successful  technology  transfer  based  on  an  intelligent  translator  for  a  domain- 
specific  specification  language  and  lessons  learned.  Translators  for  very  high-level  languages  provide  a  vehicle  for 
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making  complex,  formally-based  tools  accessible  to  the  engineering  community.  Indeed,  special-purpose  languages 
suggest  a  new  paradigm  of  software  development  by  empowering  engineers  in  other  disciplines  to  describe  (aka  program) 
solutions  to  their  computational  and  control  problems. 

2.  AN  EXAMPLE  OF  TECHNOLOGY  TRANSFER 
2.1.  The  Problems  of  Technology  Transfer 

For  several  years  the  author  was  involved  in  a  research  project  at  a  major  aerospace  corporation.  The  project 
studied  techniques  for  program  synthesis,  automatic  code  generation,  very  high-level  languages,  graphical  design  tools 
and  similar  topics.  The  goal  was  to  simplify  specification  of  software  systems  and  to  make  code  synthesis  practical  by 
working  in  a  restricted  domain. 

As  in  most  industrial  research  laboratories  there  was  the  pressure  to  show  practical  relevance  of  the  work.  To 
that  end,  the  project  developed  a  number  of  prototype  tools  that  were  considered  practical  and  useful  by  academic 
standards  (e.g.[3;  2;  8;  4;  5]). 

But  academic  standards  are  not  good  enough  to  be  accepted  by  those  responsible  for  real  products.  Several  attempts 
to  transition  some  of  the  lab’s  technology  to  product  divisions  were  met  with  universal  rejection.  There  were  several 
reasons  for  this  rejection,  most  of  them  non-technical  in  nature. 

•  Academics  tend  to  develop  tools  in  the  abstract,  i.e.,  they  solve  an  intellectually  interesting  problem  without 
regard  to  actual  applications.  When  scientists  talk  about  concepts  such  as  “completeness  of  decision  procedures” 
of  “expressiveness  of  languages,”  their  value  will  not  be  apparent  to  decision  makers.  Technology  must  be  sold 
by  describing  the  concrete  problems  being  solved,  how  much  time  is  saved,  and  how  quality  is  improved.  The 
technology  is  irrelevant,  it  is  its  impact  that  matters. 

•  People  in  charge  of  software  projects  are  extremely  concerned  about  schedule  risk.  Even  if  a  new  tool  promises 
great  time  savings,  it  will  be  rejected  if  there  is  even  minimal  risk  that  it  might  negatively  impact  the  schedule. 
Large  potential  time  savings  are  often  not  realistic  due  to  a  steep  learning  curve. 

•  Researchers  tend  to  build  tools  in  isolation  without  consideration  of  the  environment  and  the  work  process  of 
software  production.  Tools  that  require  changes  in  an  established  software  development  process  are  difficult  to 
sell. 

•  An  important  reason  for  rejection  is  the  perceived  and  often  real  lack  of  maintenance  and  support  for  systems 
that  come  out  of  research  labs. 

•  One  frequent  objection  to  the  use  of  machine  generated  code  was  readability.  From  the  academic  point  of  view, 
machine  generated  Ada  code  is  no  different  than  compiler  generated  assembly  code.  But  the  programmer  in  the 
field  will  be  skeptical  of  the  new  technology  and  will  want  to  inspect  and  understand  the  code.  As  a  consequence 
significant  effort  was  spent  on  generating  human  readable,  commented  code. 

2.2.  A  Breakthrough 

In  early  1995,  the  company  was  preparing  a  proposal  for  a  new  NASA  satellite  program.  To  justify  a  low  project 
cost  an  experiment  was  proposed  that  would  demonstrate  and  measure  the  cost  reduction  possible  through  automatic 
code  generation. 

We  were  given  an  existing  satellite  software  system  that  was  operational  in  a  simulator  environment.  The  task  was  • 
to  generate  from  specifications  one  key  module  to  achieve  a  different  functionality.  The  generated  code  was  to  be 
tested  and  validated  in  the  existing  simulation. 

After  many  failed  attempts  to  introduce  our  technology  into  the  product  divisions  we  had  finally  generated  some 
visibility  and  interest.  There  were  a  few  major  problems  though.  None  of  the  lab’s  researchers  had  any  experience  with 
the  satellite  domain;  we  could  not  even  understand  the  new  requirements.  We  had  no  domain-specific  specification 
language  and  no  idea  what  one  should  look  like.  And  we  were  only  given  four  weeks  to  complete  the  experiment.  The 
task  was  close  to  impossible.  A  cynic  might  think  that  we  were  deliberately  setup  for  failure.  More  likely,  the  problem 
was  of  our  own  making  since  we  had  created  misconceptions  and  wrong  expectations  in  our  earlier  attempts  to  “sell” 
our  technology. 

After  some  fight,  we  convinced  management  to  allocate  a  full-time  aerospace  engineer  to  the  project.  He  was  our 
domain  expert  and  brought  the  specification  language.  As  it  turned  out,  aerospace  engineers  specify  and  test  their 
control  laws  in  MatLab1.  These  MatLab  specifications  with  some  additional  information  became,  the  input  to  our  new 
tool. 

1  MatLab  and  all  other  product  and  company  names  mentioned  in  this  document  are  used  for  identification  purposes  only,  and  may  be  trademarks 
of  their  respective  owners. 
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Fig.  1.  Satellite  software  architecture  with  multiple  functional  modules  that  are  connected  to  the  realtime  executive  through  standard  interfaces. 


Using  extensive  parsing,  pretty.printing,  and  tree  manipulation  tools  that  the  project  had  developed  over  the  years, 
we  managed  to  build  a  prototype  system  that  generated  usable  code  -  at  least  for  one  example.  The  experiment  was 
successful  and  the  data  gathered  was  used  in  the  proposal.  Ironically,  the  proposal  was  not  successful:  its  cost  did  not 
fit  within  the  parameters  considered  reasonable  by  NASA  and  it  was  rejected  as  unrealistically  cheap. 

3.  SUCCESSFUL  AUTOMATIC  CODE  GENERATION 

Even  though  the  satellite  proposal  was  not  successful,  the  experiment  demonstrated  the  utility  of  our  approach 
and  gave  the  lab  some  credibility.  The  aerospace  engineer  that  participated  in  the  experiment  became  a  very  strong 
advocate  for  the  technology.  By  necessity  (e.g.,  lack  of  time),  we  had  created  a  solution  that  was  simple  and  fit  into 
the  existing  development  process  with  minimal  impact.  As  a  result  the  initial  crude  prototype  was  further  developed 
into  a  usable  system,  the  Flight  Code  Generator  (FCG),  that  is  actively  used  on  several  programs.  The  current  version 
of  the  system  employs  dataflow  analysis,  various  code  optimization  techniques,  type  inference,  and  analysis  of  finite 
state  machines. 

FCG  is  successful  because  it  (i)  is  specialized  to  a  narrow  domain,  (ii)  generates  code  that  fits  into  an  existing 
architecture,  and  (iii)  fits  into  an  established  development  process.  The  following  is  a  brief  description  of  these 
technical  aspects  of  FCG. 

3.1.  Building  Satellite  Control  Systems 

Figure  1  shows  a  reusable  software  architecture  for  satellite  control  systems.  The  realtime  executive  provides  an 
infrastructure  that  is  independent  of  the  particular  system  requirements  and  can  be  reused  across  multiple  spacecraft. 
It  connects  spacecraft  specific  device  drivers  and  functional  modules.  These  modules  perform  such  functions  as  rotating 
solar  arrays,  moving  momentum  wheels,  determine  position  based  on  various  sensors  and  so  on.  The  code  of  each 
module  is  executed  sequentially  at  an  appropriate  clock  rate.  For  each  clock  cycle  the  module  performs  the  appropriate 
computation  which  includes  reading  ground  commands  and  sending  telemetry  information.  Modules  communicate  by 
shared  variables  which  require  no  synchronization  if  the  reader  and  writer  modules  run  at  the  same  clock  rate. 

_  During  the  design  process  aerospace  engineers  (AE)  develop  the  control  laws  for  each  functional  module.  Typically  a 
single  engineer  works  on  a  module.  The  control  laws  are  coded  and  evaluated  in  MatLab  to  determine  proper  behavior. 
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Fig.  2.  Aerospace  (AE)  and  software  (SE)  engineers  cooperate  to  develop  functional  modules 


The  result  of  these  tests  are  plots  that  show  various  responses  to  control  inputs. 

Figure  2  show  the  development  process  for  an  individual  module.  A  software  engineer  (SE)  takes  the  design 
document  produced  by  the  aerospace  engineer  and  develops  appropriate  Ada  code.  This  code  is  unit-tested  and  later 
integrated  into  the  system.  Separate  software  documentation  is  produced  for  the  hand-written  Ada  code.  The  design 

document  is  also  used  as  a  basis  for  developing  ground  software  that  needs  to  interpret  telemetry  information  and 
generate  commands. 


3.2.  Tool  Support 


It  is  apparent  that  the  process  of  Figure  2  is  inefficient  and  error  prone.  But  it  leaves  plenty  of  room  for  automation 
and  the  experiment  described  in  section  2.2  would  not  have  possibly  succeeded  without  the  reusable  architecture  and 
the  process  being  in  place. 

First,  the  process  suggests  a  natural  specification  language:  MatLab.  While  the  MatLab  source  contains  all  necessary 
equations  and  formulas  as  well  as  test  code  to  produce  various  plots,  it  does  not  contain  information  about  the  kind 
of  telemetry  to  send,  the  commands  and  their  parameters  that  are  to  be  received,  and  how  to  respond  to  a  particular 
command.  Thus  the  specification  language  was  defined  as  an  extension  to  MatLab  that  includes  the  following  additions: 

•  Optional  type  information  can  be  added  to  determine  precision  of  data  and  to  select  specific  Ada  types  (e.g.  the 
support  infrastructure  contains  a  4-element  float  vector  type  as  well  as  a  quaternion  type  which  are  structurally 
equal  but  have  different  associated  operations). 

•  Telemetry  is  specified  by  listing  those  variables  whose  values  are  to  be  included  in  the  telemetry  stream. 

•  Commands  are  defined  by  a  name  and  possible  parameters. 

•  A  hierarchical  finite  state  machine  (essentially  a  textual  version  of  state  charts  [6])  specifies  the  actions  to  be 
taken  in  response  to  a  clock  tick  or  a  command. 

•  Special  comments  were  added  that  can  be  included  in  generated  Ada  code  and  documentation. 


In  addition,  it  was  necessary  to  mark  certain  inputs  (e.g.,  test  code  that  generates  plots)  so  that  it  can  be  excluded 
from  processing  by  FCG.  All  extensions  were  added  to  MatLab  using  special  comment  characters  such  that  a  source 
file  of  the  extended  language  can  still  be  processed  by  MatLab.  The  resulting  language  is  ugly  by  any  measure.  But 
that  problem  was  far  outweighed  by  the  benefits  of  having  a  single  representation  of  the  design.  Engineers  found 
surprising  ways  to  make  their  specifications  readable. 

FCG  is  a  batch  tool  written  in  Common  Lisp  that  takes  specifications  written  in  the  extended  MatLab  language 
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Fig.  3.  FCG  fits  into  the  existing  development  process  and  eliminated  virtually  all  manual  handling  of  the  Ada  code  for  functional  components. 

and  generates  the  following  outputs  (controlled  by  command  line  options) 

1.  Database  records  that  describe  telemetry  and  command  information  necessary  for  building  ground  software. 

2.  An  Ada  package  that  conforms  to  interfaces  and  conventions  of  the  reusable  architecture.  While  the  code  is 
commented  and  human  readable  it  is  ready  for  system  integration  and  does  not  require  human  modifications 

3.  A  test  environment  that  allows  interactive  or  scripted  unit  testing  of  the  generated  Ada  code.  The  test  environment 
contains  an  interpreter  that  allows  inspection  and  modification  of  all  variables,  calls  to  defined  procedure,  and  the 
simulation  of  clock  ticks  and  the  arrival  of  commands.  It  also  allows  the  generation  of  plots  that  can  be  compared 
with  those  generated  by  MatLab. 

4.  Documentation  of  both  the  design  and  implementation  of  the  module.  This  information  is  based  on  the  specifi¬ 
cations,  embedded  comments,  rind  decisions  made  by  the  Ada  code  generator 

The  new  tool  substantially  simplifies  the  development  process  with  only  minimal  additional  work  (see  Figure  3). 
The  aerospace  engineer  has  to  provide  additional  specifications  in  the  MatLab  source  and  is  now  performing  unit  tests 
of  the  generated  Ada  code.  Any  necessary  code  change  is  made  in  the  MatLab  source.  Even  with  this  additional 
work,  the  AE’s  job  is  simplified  since  the  documentation  requirements  are  reduced  and  the  communication  with  the 
software  engineer  is  eliminated. 

3.3.  A  Recipe  for  Success 

FCG  is  now  used  on  three  satellite  systems.  On  one  program  FCG  is  being  used  both  for  the  control  find  the 
payload  software  and  almost  half  of  the  software  is  automatically  generated.  While  this  is  significant,  the  system  is 
not  universally  accepted  throughout  the  corporation.  Two  problems  dominate:  The  system  lades  user  support  and 
maintenance.  Many  software  designers  refuse  to  work  within  the  confines  of  a  reusable  architecture  and  insist  on 
starting  with  a  clean  slate. 

Why  was  FCG  successful  when  much  more  elaborate  earlier  prototypes  failed?  Luck  was  an  important  part.  The 
challenge  experiment  created  the  necessary  visibility  and  convinced  management  and  engineers  of  the  value  of  the 
technology.  Without  the  strong  support  of  advocates  from  within  the  product  division,  insertion  of  new  technology 
would  not  have  been  possible.  Input  from  the  user  community  is  important.  An  internal  advocate  is  ideal.  Users 
that  feel  in  control  are  very  supportive.  Interestingly,  all  support  came  from  aerospace  engineers  whose  jobs  are  more 
difficult  with  FCG.  All  resistance  came  from  software  engineers  whose  jobs  fire  simplified  by  the  tool. 

Documentation  is  as  important  as  code.  Using  a  single  source  to  generate  code  as  well  as  documentation  and 
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other  artifacts  ensures  consistency  and  simplifies  maintenance.  Being  able  to  generate  custom  database  records  and 
documentation  was  a  major  selling  point.  .  . 

A  critical  reason  for  success  is  minimizing  risk.  In  the  FCG  approach  it  is  always  possible  to  revert  to  the  old  ways 
if  problems  should  arise.  Several  features  of  the  system  helped  to  minimize  risk: 

'Phe  learning  curve  for  the  tool  was  very  shallow.  Initial  use  (e.g.  unit  testing)  is  possible  using  straight  MatLab 

code.  _  . 

2.  The  generated  code  is  human-readable.  If  necessary,  the  code  can  be  maintained  by  hand. 

3.  The  tool  fits  into  an  existing  development  process.  I.e.,  while  some  of  the  steps  of  the  existing  process  are 

automated,  none  of  the  manual  steps  need  to  change  in  a  significant  way. 

4.  The  system  adapts  to  an  existing  architecture  and  its  interfaces.  No  software  changes  are  needed  to  accommodate 
machine  generated  code. 

3.4.  Commercial  Tools 

There  are  several  commercial  systems  that  generate  code.  But  business  reasons  dictate  that  these  systems  are  rather 
general  purpose.  Developing  systems  that  generate  custom  code  for  a  narrow  domain  is  not  commercially  viable  unless 
we  can  greatly  simplify  the  construction  and  configuration  of  such  system. 

Integrated  Systems  offers  MatrixX,  a  system  for  graphically  specifying  control  systems  and  for  generating  code 
from  such  specifications.  The  product  is  much  more  mature  and  feature-rich  than  FCG  but  suffers  from  the  lack  of 
customization  -  The  generated  code  cannot  easily  be  integrated  into  the  satellite  architecture.  MatrixX  was  actively 
considered  but  was  perceived  as  much  higher  risk  and  more  disruptive  than  FCG.  _ 

National  Instruments’  LabVIEW  and  BridgeVIEW  are  products  for  graphically  designing  data  acquisition  and  signal 

processing  applications.  ....  * 

Other  examples  of  successful  automatic  code  generators  include  parser  generators  and  attribute  grammar  systems 

as  well  as  numerous  generators  for  graphic  user  interfaces. 


4.  FINAL  THOUGHTS 

Formal  methods  are  a  means,  not  an  end.  To  become  useful  and  accepted,  computer  science  theory  must  be  packaged 
and  become  invisible.  Tool  builders  need  to  understand  both  the  formalism  and  their  end-users.  Domain-specific  tools 
provide  a  promising  vehicle  to  deliver  theory  to  practitioners.  ,  , 

Ever  higher  levels  of  specification  provide  increased  opportunities  for  formal  methods.  Specifications  based  on 
constraints  can  use  theorem  provers  to  generate  suitable  code.  Most  domains  tend  to  have  design  rides  that  can  be 
checked  using  deductive  or  model-checking  techniques.  Domain-specific  languages  appear  to  be  an  effective  delivery 
vehicle  for  formal  methods.  This,  in  turn,  should  reduce  the  cost  and  improve  the  quality  of  software. 

Maybe  domain-specific  tools  will  eventually  lead  to  a  new  software  development  paradigm,  one  where  software 

technology  empowers  everyone  to  become  a  programmer  in  her  field.  _  ,  ,  % 

While  the  FCG  experience  provides  only  one  data  point,  the  existence  of  commercial  tools  (e.g.  ose  ci  e  a  / 
is  evidence  that  suggests  that  automatic  code  generation  is  accepted  by  practitioners.  Domain  engineers  like  to  be  m 

control  rather  than  having  to  depend  on  software  engineers.  .  ‘  a 

Today  software  engineers  are  expected  to  play  experts  in  all  areas  from  human-computer  interfaces  to  fluid  dynamics 
to  fly-by-wire  systems.  Software  engineers  cannot  play  all  these  roles  and  if  they  do,  poor  software  15  ®  “ecessity. 
Instead,  software  engineers  should  be  tool  builders.  They  are  uniquely  qualified  to  make  computers  accessible  to  other 
disciplines  and  to  empower  engineers  in  other  fields  to  express  their  designs.  _ 

We  have  already  seen  how  spreadsheet  programs  have  made  almost  every  computer  user  into  a  prograxnmer.  Ub- 
viously,  not  everyone  is  successful  in  programming  their  spreadsheets.  But  for  disciplines  where  spreadsheets^ 
common  use,  «2r  programming  has  already  become  part  of  the  standard  cumculum.  In  the  ong  ^  ^s 
in  many  disciplines  will  become  programmers:  domain  specific  programming  will  become  part  of  the  cun^ 
standard  practice  in  their  discipline.  Given  the  increasing  proliferation  of  software,  this  development  seenK  mentable 
There  is  a  good  chance  that  such  a  development  will  also  alleviate  some  of  the  prob  ems  of 
and  capture.  Requirements  are  often  the  interface  between  practitioners  is  ddlerent  disciphnra  ttat  • peak. 
languages  use  different  defaults  and  different  common  assumptions.  If  the  requirements  analyst  and  the  programm 
are  experts  in  the  same  do  discipline  there  is  much  less  change  of  miscommumcation. 
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ABSTRACT 

Message  Sequence  Charts  (MSC)  is  a  graphical  trace  language  for  describing  and  specifying  the  communication  be¬ 
haviour  of  distributed  systems  by  means  of  message  interchange.  (Timed)  Maude  is  a  formal  object-oriented  speci¬ 
fication  language  which  combines  algebraic  specification  techniques  for  describing  complex  data  structures  with 
(timed)  term  rewriting  to  deal  with  dynamic  behaviour.  In  this  paper  we  show  first  how  to  formalize  MSC  in  Timed 
Maude:  Then  we  give  a  translation  of  timed  rewriting  to  untimed  rewrite  systems  and  use  this  translation  to  execute 
Message  Sequence  Charts  with  the  Elan  system,  a  powerful  tool  which  combines  Rewriting  Logic  with  a  lan¬ 
guage  of  rewriting  strategies.  We  illustrate  our  approach  with  the  bench  mark  example  of  a  railroad  crossing. 

Keywords:  Message  Sequence  Charts,  formal  methods,  term  rewriting,  real-time  systems,  tool  support 
X.  INTRODUCTION 

Currently  used  methods  in  software  engineering  use  diagrammatic  notations  such  as  object  diagrams,  scenarios,  Message 
Sequence  Charts  (MSC),  or  UML  since  their  graphical  representations  facilitate  reading,  understanding,  and  the  design  of 
systems.  Nevertheless  these  notations  suffer  from  semantical  problems,  since  their  exact  meaning  is  often  unclear.  Recently 
much  effort  has  been  made  to  overcome  some  of  the  semantical  problems  by  applying  formal  techniques  to  methods  used 
in  practice  of  software  engineering  (e.g.  [13]).  This  paper  is  another  step  in  this  direction.  We  show  in  this  paper  how  to  for¬ 
malize  Message  Sequence  Charts  in  the  executable  specification  language  Timed  Maude  and  how  to  execute  it  with  the  Elan  sys¬ 
tem. 

Maude  [2]  is  a  formal  object-oriented  specification  language  which  combines  algebraic  specification  techniques  for  de¬ 
scribing  complex  data  structures  with  term  rewriting  to  deal  with  dynamic  behaviour.  It  is  based  on  so  called  Rewriting 
Logic  (RL)  [9],  In  Maude  communication  of  system  components  is  handled  by  interchanging  messages.  Timed  Maude  [7] 
is  a  real-time  extension  of  Maude  which  adds  a  time  view  to  the  functional  and  the'process  view  of  Maude.  It  is  based  on 
Timed  Rewriting  Logic  (TRL)  in  the  same  way  as  Maude  is  based  on  Rewriting  Logic.  TRL  specifications  with  discrete 
time  can  be  easily  translated  into  untimed  rewrite  specifications  in  RL  as  we  show  in  this  paper. 

MSC  [4]  is  a  graphical  trace  language  for  describing  and  specifying  the  communication  behaviour  of  a  distributed  system 
by  means  of  message  interchange.  It  extends  interaction  diagrams  by  several  constructs  allowing  to  compose  different  dia¬ 
grams.  The  language  has  been  recommended  as  a  standard  by  the  International  Telecommunication  Union.  A  Maude  like 
model  can  be  used  to  provide  a  semantics  for  MSC  [6],  In  this  paper  we  show  how  a  basic  MSC  can  be  translated  into  Timed 
Maude  following  [5, 6].  We  present  also  a  formalization  of  two  composition  operators  for  horizontal  and  vertical  composi¬ 
tion  [8]  from  MSC-96.  The  first  operator  allows  one  to  define  the  sequential  composition  of  specifications;  the  second  one 
composes  two  systems  working  in  parallel.  Both  operators  are  formalized  using  a  syntactic  substitution  operator.  We  Ulus 
trate  our  approach  with  the  bench  mark  railroad  crossing  example  and  present  its  forinal  specification.  The  specification  is 
compositional  since  we  specify  smaller  units  and  then  glue  them  together  using  the  horizontal  and  vertical  composition  op¬ 
erators. 
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denned  modules*  2  T “  "“  **  «“ 

to  Elan  based  on  the  interpretation  of  TRL  in  R  r  T  “  ^  by  translat5nS  TRL  semantics 

iflcadon  of  the  railroad  crossnigus^ngEUn!*  ^  paPer  we  s^ovv  how  to  execute,  analyze  and  improve  the  MSC  spec- 

°f  MSC's  W  ^  specif, canons,  i,  Hows 

a  shon  °r m- an<i  Timed  M,ude' in  sec,ta  3  « 

5  we  formalize  vertical  and  horizontal  composition  of  MScTln  sect"  Ma“d'  “m““cs  ofMSC  In  section 

2.  FORMAL  BACKGROUND 

Timed  Rewriting  Logic  (TRL)  [7]  is  an  extension  of  Rewriting  Logic  (RL)  roi  for  • 

time  by  architnedean  monoids.  Time  evolves  by  executing  sen^te^TesriEach^rukis  mnlabel^by  a^mTstotp  htd^cadnE 
the  tone  needed  for  executing  a  rewrite  step.  The  inference  rules  of  TRL  are  similar  to  those  of  RL  The  t!IT7ff 
“a  m"*  C°”slderatlon  of  llme  stamps,  the  synchronous  replacement  rule  and  bounded  (i.e.  0-time)  reflexivity 

jmA^^S^eC,^Cftl0n  ’S  3  P3^^  ^  fQm1  ®^+)>  where  TfR+J  is  a  signature  containing  proper sons  and  operation  symbols 

Ax  is  a  set  of  equations  and  timed  rewrite  rules  of  the  form,  t,  -  a  r->  ,2 ,  where  a  is  a  label  denoting  an  ac&m  or  a  system 

“^,*,7  ”7  “°"Si"8  “  "*  ”nd'rlyi0g  -““/mono/dR,!,  and  t„  ,2  are  fyterms  coding  sysretn  »es  ,eonfis. 

antvts).  Informally,  dns  means  that  the  system  evolves  from  state  t,  to  t2  by  performing  the  sKp  a  in  time  r.  TRL  has  dm  fol- 
lowing  deduction  niles  (plus  rules  for  equational  reasoning): 

1.  Timed  Transitivity  (TT).  For  each  t,,  t2,  t3  €  T(Z,X),  r,,r2e  R+ 

tj  —a  rj— >t2,  t2  — b  r2— >t3 

tj— a;b  rj+r2  — >t3 

2.  Synchronous  Replacement  (SR).  Let  {xn,...,Xik}  =FV(to)nFV(u0)  be  the  intersection  of  the  free  variables  of  t*,  and  Uq  For 

each  to,  t,....,  ^  uq,  Uj,...,  un  e  T(Z*),  re  R,  *  ^ 

to  -  a  r  ->  u0,  ti|  — aij  r— >  u^,...,  ^  ^  r  ->ui(; 


. tn)  ~a(ai1 . aj,)  r— >  u0(uj,...,un) 

3.  Timed  Compatibility  with  =  (TCE).  For  each  tlt  t2,  u,,  u2  e  T(2yC),  rj,  r2  e  R+, 
tl  =  ul>  ri  - r2>  ui  —a  fj  — >u2,  u2  =  t2 

tj  -a  r2— >  t2 

4. 0-time  Reflexivity  (0-R).  For  each  t  e  T(X,X) 
t—  t  0— >t 


1 .  Examples  of  arithmetical  monoids  are  discrete  time  models  like  natural  numbers 

31$ 


as  well  as  continuous  time  models  like  re- 
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A  term  tis  called  static  if  it  does  not  change  over  time,  i.e.  for  all  r,  t— t  r— >t  holds,  and  if  t  — a  r— >t' holds  for  some  r, 
then  t = t'.  If  a  term  t  is  not  static  then  we  call  it  dynamic  and  denote  it  by:  op  dynamic  t  (see  the  applications  section).  Similarly, 
a  sort  s  is  static  iff  it  contains  static  terms  only,  otherwise  it  is  called  dynamic . 

Timed  Maude  is  a  formalism  for  specifying  object-oriented  distributed  systems  based  on  TRL.  It  borrows  the  object-oriented 
concepts  of  Maude.  An  {object)  class  is  declared  by  an  identifier  and  a  list  of  attributes  and  their  types.  An  object  is  represented 
by  a  term  comprising  a  unique  object  name,  an  identifier  for  the  class  the  object  belongs  to,  and  a  set  of  attributes  with  their  values. 
We  will  use  capital  letters  for  names  and  the  corresponding  small  letters  for  objects  being  in  certain  states  denoted  by  constants; 
e.g.  the  term  tg  =  <TG :  TrainGate  I  state  :  up>  represents  an  object  tg  with  name  TG  belonging  to  the  class  TrainGate,  and  the 
attribute  state  has  value  up.  In  the  following  we  often  omit  the  class  and  the  name  of  the  attribute  and  write  simply  <CIG  I  up> . 
We  assume  that  the  set  of  possible  names  is  a  disjoint  sum  of  a  set  of  object  names  and  a  set  of  gate  names.  A  message  m  is  a 

term  of  the  form  (X,  dt,  Y)  that  consists  of  object  or  gate  names  X,  Y  of  sort  names  and  data  dt  of  sort  data  carried  by  the  message?. 

X  and  Y  can  be  understood  as  the  sender  and  the  receiver  address,  respectively.  If  X  (Y,  resp.)  is  a  gate  name,  then  it  is  to  be 
understood,  that  the  exact  sender  (receiver,  resp.)  address  is  unknown.  Letters  “g  ”  and  “g ”  will  be  used  for  gate  names  (gj  and 
gj  are  dual  names  which  can  occur  in  “dual”  specifications).  Moreover,  if  X  is  a  gate  name,  then  we  say  that  the  message  m  is 
received  from  the  environment,  similarly,  if  Y  is  a  gate  name  then  m  is  sent  to  the  environment .  A  configuration  is  a  multiset  (or 
bag)  of  messages  and  objects.  Formally,  configuration  c  is  denoted  by  a  term  of  the  form: 

®  ...  ®  mk  ®  Oj  <S> ...  ®  Oi 

(shortly  written:  mi ...  mk  Oi ...  Oj)  where  ®  is  a  binary  function  symbol  denoting  multiset  union.  A  Timed  Maude  program 
makes  computational  progress  by  rewriting  its  state.  A  rewrite  step  has  the  form 
mj ...  mk  Oj ...  Oj  —  a  r  — >  ni ...  np  ...  ow  . 

The  rule  says,  that  after  receiving  messages  m  j  ...  mk  the  objects  which  occur  on  both  sides  of  the  rule  change  their  states, 
objects  which  do  not  appear  on  the  right  hand  side  are  deleted,  objects  which  do  not  appear  on  the  left  hand  side  are  created, 
and  messages  nj ...  np  are  sent;  all  these  happens  in  time  r.  Simple  Maude  allows  only  so  called  asynchronous  rules,  i.e. 
rules  where  1=1. 

3.  INTERPRETING  TRL  IN  RL 

In  this  section  we  show  how  to  translate  timed  TRLspecifications  to  untimed  rewrite  systems  written  in  RL  [11].  In  prin¬ 
ciple  one  could  choose  also  any  other  term  rewriting  formalism,  but  RL  is  specially  convenient  due  to  its  conceptual  sim¬ 
ilarity  to  TRL.  Our  translation  works  for  all  linear  TRL  specifications  with  discrete  time  (and  without  equatiorial  axioms) 
and  therefore  can  be  applied  to  more  general  TRL  specifications  than  the  first  translation  of  TRL  to  RL  by  Olveczky  and 
Meseguer  [10]. 

3.1  Definition 

Let  Sp  =  (Z(R+),  Ax)  be  an  arbitrary  TRL  specification  such  that  Ax  contains  rewrite  rules  only  and  each  rewrite  rule  has 
time  stamp  0  or  1.  We  define  the  RL  interpretation  Int(Sp)  =  (Int(E(R+)),  Int(Ax))  as  follows: 

The  signature  Int(X(R+)  extends  1(11+)  with  the  following  new  (polymorphic)  function  symbols  for  every  dynamic  sort  s: 
Go:s— >s,  D:s— >s, 

clean :  s  — >Bool,  [_](-):  Time,  s—>s. 

The  function  Go  (Go  stands  for  go)  is  used  to  mark  dynamic  arguments  where  time  must  progress.  The  function  D  is 
used  to  mark  where  time  has  already  progressed  (D  stands  for  done).  These  functions  allow  to  synchronize  progression  of 
time  in  a  term.  The  function  clean  ensures  that  a  term  (is  ground  and)  does  not  contain  Go  or  D.  The  function  [J(-)  indi¬ 
cates  the  time  available  for  executing  a  term. 

2.  In  Maude  a  message  is  modelled  by  a  pair  of  the  form  (dt,  Y)  where  Y  must  be  a  name  of  an  object,  not  a  gate.  There  is  no 
concept  of  gate  in  Maude. 
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(ii) 


(iii) 


(iv) 


The  rewrite  theory  Int(Ax)  contains  the  following  rules:  The  rules  (i)  allow  us  to  simulate  the  0-time  rules  on  terms  which 
H  11  n?  OF  •  S 1S  aSSUrCd  ^  dCan  funCd0n- The  leanness  condition  is  needed  to  ensure  that  the  RL  rules 

scnbe  how  time  progresses  when  the  term  is  rewritten;  it  leaves  static  terms  unchanged  whereas  dyn'Lc  terms  re 
mZTa'T^  n  ““  h“  “  Pr0Paga"  d°™'  ““  D  if  ”  “  readJr  "i*  a  »I«nn.  Rule  (iii)  serves  to  pull 

up  the  D  function  using  another  term  mapping  called  A.  p  u 

(i)  For  each  0-time  rule  t  -  a  0->t'  6  Ax  we  have  the  corresponding  conditional  rule: 

t — >ta  if  clean(t), 

For  each  rule  t — a  l->t'  e  Ax  we  have  the  corresponding  conditional  rule- 

Go(t)  — >r(o, 

For  each  function  symbol  f :  S|, ... ,  s„  — >s  €  1(1*+)  we  have  a  rule  to  pull  up  the  D  function: 
f(A(xl> . A(x„))  — >D(f(xlf ... ,  xn)) 

Finally,  for  each  dynamic  sort  s  and  a  variable  x  of  sort  s  we  have  a  rule  to  initiate  the  next  time  step- 
[n+l)(D(x))  — >[n](Go(x)). 

The  clean  function  is  axiomatized  by  the  following  equations: 

clean(Go(x))  =  False,  clean(D(x))  =  False, 

clean(c)  =  True,  clean(f(x, . xn))  =  clean(xi)  &  -  &  clean(xn), 

for  each  constant  symbol  c  e  I(R+),  and  each  n-ary  function  symbol  f  e  X(R+). 

The  term  mapping  T:  T(I(R+),  X)  ->T(Int(I(R+)),  X)  is  defined  as  follows: 

(1)  HO  =  t  if  t  is  a  member  of  a  static  sort; 

(2)  T(t)  =  D(t)  if  the  term  t  is  a  member  of  a  dynamic  sort  but  contains  no  variables  of  dynamic  sorts; 

(3)  r(t)-Go(x)  if  t  =  x  and  x  is  a  dynamic  variable  (sis  the  syntactic  identity); 

(4)  F(t)  =  f(r(t,) . T(tn))  if  t  b  f(tj , ... ,  tn),  and  t  is  of  dynamic  sort  and  contains  variables  of  dynamic  sorts 

The  mapping  A :  X —>T(Int(Z(R+)),  X)  is  defined  by 

A(x)  =  x  if  x  is  of  a  static  sort,  else  A(x)  =  D(x). 

In  [II]  it  has  been  shown  that  the  interpretation  of  TRL  in  RLis  correct  in  the  sense  that  a  timed  rewrite  formula  is  de- 
“  a  linear  TRL  sPecification  if  and  only  if  its  interpretation  is  deducible  from  the  RL  interpretation  of  the  spec- 


4.  FORMALIZATION  OF  MSC 

MSC  is  a  trace  language  for  description  and  specification  of  communication  behaviour  of  system  components  and  their 
environment  by  means  of  message  interchange  [4].  There  is  an  interesting  relation  between  Timed  Maude  and  MSC,  in 
particular,  there  exists  a  formal,  Maude  like  semantics  of  MSC-96  [6]. 

Basically,  a  MSC-diagram  describes  a  system  behaviour  in  the  following  way  [4]:  the  behaviour  of  an  object  (or  in¬ 
stance)  is  represented  by  a  vertical  line  defining  a  total  ordering  of  its  actions.  Such  a  vertical  line  starts  with  an  empty  box 
and  ends  with  a  black  box.  If  a  message  is  being  sent  from  one  object  to  another,  then  this  is  indicated  by  a  horizontal  arrow 
directed  from  the  sender  to  the  receiver.  Message  passing  is  asynchronous;  therefore  it  corresponds  to  two  events:  sending 
and  receiving  a  message.  Messages  sent  to  (received  from,  resp.)  the  environment  correspond  to  out  (in,  resp.)  arrows  labelled 
by  gate  names.  One  may  specify  the  time  a  message  deliverance  will  take  by  giving  a  real  number  under  the  horizontal  ar¬ 
row.  The  initial  (final)  states  of  an  MSC  are  the  states  which  occur  directly  after  (before,  resp.)  an  empty  (black,  resp.)box.There 
are  only  three  kinds  of  atomic  steps  an  MSC  instance  can  execute:  sending  or  receiving  a  message,  creating  or  stopping 
another  object,  and  a  special  action  which  changes  only  the  state  of  an  object.  The  first  MSC  diagram  shown  on  figure  1 


i 
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describes  a  train  gate  (named  “TG”),  which  is  initially  in  up  position,  and  which  moves  down  after  receiving  message  n\.om 
from  message  gate  g. 

Basic  MSC  can  be  formalized  in  Timed  Maude  as  follows  [5, 6]:  For  any  instance  O  of  aMSC  diagram  we  introduce  an 
object  of  appropriate  class  which  contains  an  attribute  called  state,  i.e.  <0 :  Class  I  state :  s  >.  For  simplicity,  states  will  always 
be  denoted  by  constants  in  this  paper.  Different  object  actions  are  separated  by  intermediate  states.  Object  states  may  be 
described  using  (local)  conditions  denoted  by  hexagons  (see  below).  Any  message  sent  is  split  into  a  send  and  a  receive 
part  (indicated  by  “!”  and  “?”  resp.).  In  general  the  underlying  set  L  of  atomic  steps  is  of  the  form  {?,  m, !  n,  start,  stop,  x, 
aC[,...,  acn)  where  “start”  stands  for  creating  an  object,  “stop”  for  deleting  an  object,  “x”  for  time  elapse,  and  “acj’ ,...,  acn 

stand  for  special  actions.  Finally,  we  introduce  a  rewrite  rule  for  any  action  as  follows:  ‘ 

rl  <Olstate:s>  —  !m  0— > <01  state  :s'>m. 

**the  object  named  O  sends  message  m  and  changes  its  state  from  s  to  s  in  0-time 

rl  m<0 1  state :  s>  — ?m  0->  <0 1  state :  s'> . 

**the  object  named  O  receives  message  m  and  changes  its  state  from  s  to  s  in  O-time 

rl  start(o)  —  start o  0— >o. 

**the  object  named  O  is  created  in  0-time 

rl  stop(o)o— stopo  0— >e3. 

**the  object  o  is  deleted  in  0-time 

rl  <0 1  state :  s>  -  ac;  0->  <0 1  state  :s'>. 

**the  object  named  O  performs  the  special  action  aq  changing  its  state  in  0-time 
rl  Wr(r  1  +  r2)  —  X  rl  — >  ttimerfo)  • 

**the  value  of  timer  tt;mer  is  decreased  by  q  in  time  ri 

In  all  but  the  last  case  we  say  that  the  object  named  O  performs  the  action  a  e  L  (e.g.  TG  performs  the  action  ?mcom).  Unless 
stated  otherwise,  we  will  consider  actions  of  the  form  t,  ®...®  tn®  a ,  ae  L,  and  of  the  form  tj(x)  ®...  ®  tn(x)  only  for  ti  e 
T(S,X),  i.e.  actions  performed  by  one  object  only  or  rules  where  all  components  perform  time  step  X.  For  simplicity,  we 
will  write  “a”  for  the  former  and  “x”  for  the  latter. 

The  semantics  of  MSC's  time  aspects  is  based  on  the  following  assumptions  (cf  [6]):  All  terms  are  static  per  default, 
unless  stated  otherwise.  Alt  actions  a  e  L,  except  of  x,  take  0-time.  Time  constraints  imposed  on  an  object  behaviour  or  a 
message  deliverance  are  modeled  by  timers  attached  to  object  states  or  to  messages,  respectively.  An  object  can  spawn 
multiple  timers  running  in  parallel.  An  atomic  state  (i.e.  without  timers)  can  be  declared  either  as  static  or  as  dynamic.  A 
static  state  can  last  arbitrarily  long,  whereas  a  dynamic  state  is  supposed  to  change  in  time  (i.e.  its  duration  is  0-time  units). 
In  this  paper  we  assume  that  the  equational  axioms  concern  only  data  carried  by  messages  and  the  multisum  operator  ®. 

Formally,  we  define: 

4.1  Definition 

A  MSC-specification  SP  is  a  tuple  of  the  form  (Z(R+),  Ax,  In,  Fin),  where 
.  (Z(R+),  Ax)  is  a  TRL-specification4  such  that  the  underlying  set  of  atomic  labels  as  well  as  rewrite  rules  and  axioms  forming 

Ax  have  the  form  described  above;  _ 

.  If  a  gate  symbol  g  (g,  resp.)  occurs  in  signature  KTR+),  then  the  dual  symbol  g  (g,  resp.)  does  not;  moreover,  we  assume  tha 
for  each  gate  symbol  there  is  exactly  one  object  which  communicates  through  the  gate. 


4.  FortheTate^f^^Hcity^e^eat  here  (flat)  TRL-specifications  instead  of  Timed  Maude  specifications  in  general. 
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•  In  is  a  set  of  objects  in  initial  states  and  Hn  is  a  set  of  objects  in 
constants). 

•  Objects  having  different  names  must  have  different  states. 


terminal  states,  both  kinds  of  states 


are  atomic 


(i.e.  denoted  by 


The  interface  of  SP  is  given  by  the  set  of  gate  symbols  occurring  in  KR+).  A  configuration  c  =  o-, ...  o- 
resp.),  if  c  =  In  (c  =  Fin,  resp.).  1  *m 


is  called  initial  (final. 


4.2  Definition 

Let  SP  be  a  MSC  specification.  A  partial  trajectory  is  a  finite  sequence  of  configurations,  actions,  and  time  values  c0  a, 
r,  c,...cn.,  an  rn  cn  such  that  c0  is  the  initial  configuration  and  for  i  =  0,...,  n  -  1  one  of  the  following  conditions  holds: 

*  m  is  a  message  received  from  environment,  aj+1  =  ?m, 
and  mcj  —  ?m  ri+1->ci+1; 

*  m  is  a  message  sent  to  the  environment,  a^+j  =  !m, 
and  C;  —  !m  ri+1->ci+1m; 

*  ci  ai+i  ri+l  — >  ci+i  in  any  other  case. 


A  partial  trajactory  is  a  trajectory  if  in  addition  c,  is  the  ftnai  configuration,  a,  r,  a2  r2 ...  a„  r„  is  a  (partial)  trace  of  SP  iff 
there  exists  a  (partial)  trajectory  tr  of  the  form  c0  aj  rj  Cj...cn.j  an  rn  cn. 

Note  that  for  any  (partial)  trajectory  tr  messages  sent  to  or  received  from  the  environment  are  not  part  of  the  configura¬ 
tions  cj.  In  this  way  we  abstract  from  the  moment  when  messages  are  sent  or  received  by  the  environment,  because  the 

communication  is  asynchronous  and  these  messages  are  not  a  part  of  a  system  configuration.  This  definition  of  trajectories 
allows  us  to  specify  system  behaviours  in  a  compositional  way. 


5.  COMPOSITION  OPERATORS 

In  this  section,  we  are  going  to  formalize  two  MSC  concepts  in  Timed  Maude  which  we  call  vertical  and  horizontal  com¬ 
position  (cf  [5]).  We  define  first  the  vertical  composition  (which  corresponds  to  so  called  weak  sequencing)  by  means  of 
state  identification  [8],  Then  we  consider  parallel  composition  of  components  called  horizontal  composition  defined  as  a 
simple  form  of  pushout  using  readdressing  of  messages  [8],  Syntactically  we  define  both  constructs  using  a  renaming  op¬ 
erator.  Vertical  and  horizontal  composition  differ  in  what  is  being  renamed:  in  the  first  case  we  substitute  state  names  for 
state  names,  in  the  second  object  names  for  gate  names. 

The  renaming  operator  is  defined  as  follows:  Let  SP  be  a  MSC-specification  and  let  Pl . pn,  q......  qn  be  constant  sym¬ 
bols  such  that  the  sort  of  q;  is  identical  with  the  sort  of  p.  Then  a  =  (op  p,  ->  q, . op  pn  ->  qn)  is  a  signature  morphism 

renaming  p,,...t  Pn  into  q, . qn.  The  specification  Sp  *  o  is  obtained  from  Sp  by  simultaneously  substituting  qi,.„,  q„  for 

Pl . Pn  in  S^' The  foraiula  ^ is  obtained  from  $  by  renaming  p,,...,  pn  into  q, . qn.  Similarly,  if  A  is  a  set  of  axioms, 

then  A°  =df  {<J>°  I  <j>  e  A).  Below,  we  will  substitute  only  object  names  for  gate  names  (both  of  sort  Identifier)  and  state 
names  for  state  names. 


5.1  Vertical  composition 

In  our  semantics  we  define  vertical  composition  of  two  MSC-specifications  by  means  of  state  identification.  Namely,  the 
final  states  of  the  first  specification  can  be  identified  with  the  initial  states  of  the  second  one,  provided  that  they  correspond 


5.  Semantically,  SP*  a  corresponds  to  the  translation  “translate  SP  via  o’*  where  the  specification-building  operator  “translate”  of 
usual  algebraic  specifications  is  extended  to  MSC-specifications  in  the  obvious  way  [12]. 
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to  equally  named  objects.  The  initial  set  of  the  first  specification  yields  the  initial  set  of  the  resulting  specification  and  the 
final  set  of  the  second  specification  yields  the  final  set  of  the  resulting  specification.  We  assume,  that  the  specifications 
share  the  same  basic  data  structures  (like  multisets,  numbers,  or  lists),  but  have  disjoint  sets  of  states. 

Formally,  let  Sp,  =  (X(R+),,  Ax,,  In,,  Fin,),  5p2  =  (I(R+)2,  Ax2,  In2,  Fin2)  be  two  specifications  such  that  X(R+),  and 
I(R+)2  are  identical  except  that  the  corresponding  sets  of  constant  symbols  denoting  states  must  be  disjoint,  and  that  Ax, 
and  Ax2  contain  the  same  equations.  Let  Fin,  =  {o,',...,  on'},  In2  =  {oj,...,  on)  and  suppose  that  {st, st„'},  {st2,.„,  stjJ 

are  the  corresponding  final  and  initial  states  of  the  objects  named  O, . On,  respectively  (i.e.  Fin,  and  In2  describe  states 

of  the  same  objects).  Then  a  =df  (op  st, '  ->  stj ,...,  op  st^  ->  st„)  is  a  signature  morphism  which  identifies  the  final  states  of  the 
first  model  with  the  initial  states  of  the  second  model. 

5.1.1  Definition 
The  specification 

5p,  Z  Sp2  =df  (2(R+)i  u  ^(R+>2.  Axi  vj  Ax2,  In,,  Fin2)  *  a 
is  called  vertical  composition  of  5p,  and  Sp^. 


Figure  1.  Vertical  composition 


Let  us  observe  that  o  has  been  derived  from  the  initial  and  final  states  of  Sp,  and  Spi  and  therefore  the  resulting  specifi¬ 
cation  does  not  depend  on  o.  The  set  of  initial  states  of  5p,  Z  Sp2  is  In  ,®  the  set  of  final  states  is  Fin2  (which  is  equal  to 
Fin2°since  a  renames  only  states  of  Spx). 

5.1.2  Example 

Let  us  consider  a  train  gate  TG  of  class  TGate,  that  can  be  in  two  positions:  up  or  down.  Initially  it  is  in  up  position,  then 
it  moves  down  immediately  after  receiving  message  rncom;  Let  us  also  consider  a  train  gate  which  is  initially  in  down  po¬ 
sition  and  moves  up  after  receiving  message  mpassed.  Let  these  messages  have  the  form:  meom  =  (g,  com,  TG),  mpasse(i  — 
(g,  passed,  TG),  where  g  is  a  gate.  (Let  us  remind,  that  for  a  message  gate  g,  “g"  and  “g”  are  dual  names.)  These  two  train 
gates  can  be  specified  as  follows  (we  skip  the  class  names): 
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Train  gate  specification  TGate_specl  (see  the  top  of  figure  1): 

°P  uPl .  down, :  — > state . 

uPl :  initial ,  down, :  final . 
op  dynamic  com :  — >  data . 

**  this  ensures  that  m^  is  dynamic  and  therefore  will  be  delivered  immediately 
rl  “com  <TG  I  uPl>  -  ?  mcom  0->  <TG  I  downi> . 

**  ^ train  ®ate  moves  down  immediately  after  receiving  message  mcom 


Tram  gate  specification  TGatc^spcc,  (see  figure  1): 

°P  up2 ,  down2 :  —>  state . 

down2 :  initial ,  up2  :  final . 
op  dynamic  passed :  — >  data . 

*•  this  ensures  that  mpassed  is  dynamic  and  therefore  will  be  delivered  immediately 
rI  mpassed  <TG  I  down2>  -  ?  mpassed  0->  <TG  I  up2> . 

**  the  train  gate  moves  up  immediately  after  receiving  message  mpassed 


We  can  compose  these  two  specifications  to  a  specification  Kmjpt  It  is  defined  as  Ttkujm  z  TG,te  spec,  using 
e  tenamtng  fop  down,  ->  down,).  It  specifies  a  train  gate  which  can  be  in  two  positions:  np,  down,  and  which  moves 
down  immediately  after  receiving  message  mOT  and  moves  up  immediately  after  receiving  message  m_a  (see  the  right 
and  side  of  figure  1).  The  sets  of  initial  and  final  states  are  as  follows:  In  =  {<TG  I  up,>),  Fin  .  (ZTG  |  up2>). 


5.2  Horizontal  composition 

Using  horizontal  composition  Message  Sequence  Charts  system  components  can  be  composed  for  working  in  parallel  The 

objecTS, VertiCal  C°raP0Si,iOn  “  'ha' M  8l“'  'h'  COmPO"e",S  M  a'0"8  **““  of 

Let  SPl  =  (Z(R+) , ,  Axj,  In,,  Fin,)  and  Sp,  =  (I(R+)2,  Ax2,  In2>  Fin2)  and  let  g„...,  g„  be  all  those  gate  symbols  such  that 
g,  occurs  m  one  of  the  specifications  and  g,  occurs  in  the  other.  Suppose,  that  the  object  named  0=,  communicates  through 

*  gir  .  “  thr0U£h  the  gate  ®’  f0r  ‘  “  1"“’  n  (0ji  and  0ki  are  uni£lue,y  determined  according  to  the  definition  of 
MbC-specincations).  Let  the  substitution  a  have  the  form: 

(op  g,  ->  Oj,,...,  op  gn  ->  Ojn,  op  g,  ->  Ok,,..„  op  gn  ->  Ofcn). 

Moreover  we  assume,  that  the  specifications  share  the  same  basic  data  structures,  i.  e.  they  are  defined  by  the  same 

classes  may  overlap).  We  assume  also  that  auy  gate  different  from  g„...,  g„  occurs  at  most  in  one  of  the  specifications  Sp, 


5.2.1  Definition 
The  specification 

©  Sp,  =df  (Z(R+) ,  u  Z(R+)2,  Ax,  u  Ax2,  In,  vj  In2,  Fin,  u  Fin2)  *  a 
is  called  horizontal  composition  of  5P,  and  Spz. 

Specifications  SPl  and  Sp,  are  composed  along  gates  g„...,  gn.  Let  us  observe  that  the  substitution  a  is  unique  and  that 
the  interface  of  5p,  ©  Sp,  is  given  by  those  gates  which  occur  in  precisely  one  of  the  components. 
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6.  APPLICATION:  RAILRAD  CROSSING 


We  illustrate  our  approach  with  the  bench  mark  example  of  railroad  crossing  (e.g.  [3]).  First  we 
tual)  specification,  then  its  graphical  and  formal  counterparts,  and  finally  its  translation  to  Elan 


present  the  informal  (tex- 
[1]. 


Informal  description 

A  railroad  crossing  consists  of  traingate  TG  and  a  train  track  T  which  has  sensors  attached  to  it.  (see  figure  2).  Trains  are 
moving  along  a  track.  When  a  sensor  detects  an  incoming  train  on  the  track  it  sends  immediately  the  message  m^  to  the 
train  gate.  When  a  sensor  detects  that  a  train  has  passed  the  crossing  it  sends  immediately  the  message  mpassed  totoe  train 
gate.  The  tram  gate  can  be  m  two  positions:  up,  down.  It  is  initially  in  position  “up”,  it  moves  down  after  receiving  a  mes¬ 
sage  nw  and  moves  up  after  receiving  a  message  mpassed.  We  impose  the  following  time  constraints  on  the  system  be¬ 
haviour: 

•  Trains  are  separated  by  a  period  of  at  least  8  minutes. 

•  A  sensor  detects  the  arrival  of  a  train  before  the  train  reaches  the  train  gate.  It  sends  the  message  rncom  to  the  train  gate  as  soon 
as  it  detects  a  train  arrival  and  the  message  mpassed  as  soon  as  the  train  has  passed  the  crossing. 

•  The  tram  gate  moves  immediately  down  (up,  resp.)  from  position  up  (down,  resp.)  after  receiving  message  mcom  (m 

resp.).  passe  ’ 

•  Every  message  is  delivered  immediately  (in  0-time). 


6.1  Formal  design 

An  abstract  design  of  this  system  can  be  given  by  a  Message  Sequence  Chart  which  shows  the  message  flow  and  the  real¬ 
time  constraints.  The  timings  of  a  message  deliverance  are  indicated  by  a  time  value  below  the  message  arrow.  Setting  a 
timer  in  an  object  (e.g.  tfap  see  figure  2)  is  indicated  by  a  double  triangle.  Timers  are  set  with  certain  values  (tfar  is  set  with 
value  8).  Time-outs  are  indicated  by  arrows  starting  in  the  double  triangles. 


A  Message  Sequence  Chart  showing  the  railroad  crossing  is  given  in  figure  2.  The  train  gate  TG  is  modelled  as  in  section 
4.  The  behaviour  of  train  and  sensor  is  described  by  T.  A  train  is  initially  in  state  far.  A  timer  is  set  to  8  time  units  ensuring 
the  8  minutes  distance  between  two  trains.  Sometime  after  the  time-out  of  the  timer  the  message  n\.om  is  sent  changing  the 
state  of  T  to  at  (indicating  that  a  train  has  arrived  at  the  crossing).  Later  the  message  n^ed  is  sent  and  the  state  of  T  is  set 
back  to  far  (indicating  that  the  train  has  left  the  crossing). 

The  corresponding  Timed  Maude  specification  is  defined  as  horizontal  composition  of  the  specification  TGate_spec  of  sec¬ 
tion  4  and  a  specification  Trains_spec  of  train  and  sensor.  These  specifications  are  derived  from  the  decomposition  of  the 
MSC  for  the  railroad  crossing  (figure  2)  into  two  parts  T  and  TG,  see  figure  3.  A  train  T  (with  class  name  Train)  is  an  object 
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with  an  attribute  storing  information  about  the  next  train.  The  attribute  of  the  train  gate  object  TG  (with  class  name 
“TGate”)  stores  information  about  the  gate  position.  Let  the  messages  mcom  and  mpassed  be  of  the  form  (T,  com,  g), 
(T,  passed,  g),  respectively. 

The  train  specification  Trains_spec is  as  follows  (see  the  MSC  T  on  the  left  hand  side  of  figure  3): 
op  far;,  far',  farf,  at :  —>  state , 
far; :  initial ,  farf :  final . 

•*  the  states  are  static  and  can  last  arbitrarily  long  . 

op  dynamic  com,  passed  :—>  data, 
tfar :  Time  —>  Timer . 

»»  messages  mcom,  mpasscd  will  be  delivered  in  0-time  because  com,  passed  are  declared  dynamic 
rl  <T  I  farj>  —  set  tfar  0  ->  <T  I  tfar(8)  ®  far;> . 

**  timer  tfar  is  set  and  in  8  minutes  a  train  may  come 
rl  <T  I  tfar  (0)  ®  farj>  -  t_out  tfar  0  ->  <T  I  far'> . 

••  8  minutes  elapsed,  the  timer  times  out,  and  the  train  may  appear  any  time 
rl  <T  1  far'>  -  !mcora  0  ->  <T  I  at  >  mcom . 

♦♦train  detection  immediately  triggers  sending  message  mcom  immediately 
rl  <T  I  at>  !  nipassed  0  >  <T  I  farj>  nipassed  . 

•♦  train  passed  and  message  mpassed  is  immediately  sent 

The  formal  specification  Spec  of  the  railroad  crossing  is  defined  as  horizontal  composition  of  Trains_spec  and  TGatejspec,  i.e.: 
Spec  =df  Trains_spec  ©  TGate_spec. 

The  underlying  substitution  a  has  the  form  c  =  Ci<J2  where  o1  =  (op  g  ->  S,  op  g  ->  T)  and  o2  =  (op  g  ->  TG,  op  g  ->  S).  Let  us 
also  observe,  that  the  initial  and  final  sets  are  as  follows: 

In  =  (<T  I  state  :  far;>,  <TG  1  state  :  upi>).  Fin  =  {<T  1  state  :  farf>,  <TG  I  state  :  up2>} . 


g  g 


g  g 


Figure  3.  The  components  of  the  railroad  crossing 

6.2  Implementation 

In  this  subsection  we  implement  the  above  specification  in  Elan.  The  specification  is  composed  of  three  modules:  the  mod¬ 
ule  template  containing  the  declaration  of  basic  sorts  and  operations  (we  skip  this  module  because  of  lack  of  space),  the 
module  tGate_spec  specifying  the  train  gate,  and  the  module  trains_spec  specifying  the  whole  railroad  crossing.  The  mod¬ 
ule  trains_spec  imports  the  module  tGate_spec  which  in  turn  imports  template. 


TG 

T1 

(  UP  ) 

mcom 

- ► 

^  (  dov 

pD 

mpassed 

-102- 


The  module  tGate_spec  is  a  literal  translation  of  TGate_spec according  to  definition  3.1. 

module  tGate_spec 
import  global 

template; 

end 

operators  global 

upl  :  state ;  up2 :  state;  down2 :  state ; 
com :  data ;  passed :  data ; 

TG :  obn ;  T :  obn ; 
end 

rules  for  conf  global 

[]  m(T,  com,  TG)  *  <TG  I  upl>  =>  <TGIdown2>  end 
[]  m(T,  passed,  TG)  *  <TG  I  down2>  =>  <TG  I  up2>  end 
end 
end 

For  the  specification  of  T  we  follow  the  interpretation  schema  except  in  case  (ii)  where  the  distributivity  of  Go  is  restrict¬ 
ed  to  configurations  without  pending  messages  and  where  time  progress  in  a  timer  is  modelled  as  time  progress  in  a  whole 
object.  The  first  change  ensures  that  all  messages  will  be  read  before  the  time  progresses,  the  second  makes  the  specifica¬ 
tion  more  compact.  Let  us  observe  that  every  0-time  rule  applies  only  to  terms  having  no  variables,  therefore  we  do  not 
need  the  cleanness  function. 


module  trains_spec 

import  global  tGate_spec ; 
end 

operators  global 

fari :  state ;  far' :  state ;  farf :  state 
t_far(  @  )  :  ( int )  timer ; 
end 

rules  for  conf 

s,  x,  y :  state ; 
cl,  c2 :  conf; 
n :  int ; 
global 

[]  <T  I  fari> 

[]  <T  I  t_far(0)  &  fari> 

[]  <fT  I  farV 

[]  <T  I  at> 

[]  D(cl)  *  D(c2) 

[]  Go(<TG  I  x>  *  <T  I  y>) 
[]  Go(<TG  1  x>) 

[]  Go(<Tlfarf>) 

[]  Go(<T  I  t_far(n)  &  s>) 

[1  [n]  D(cf) 

end 
end 


at :  state ; 


=> 

<T  1  t_far(8)  &  fari> 

end 

=> 

<T  1  far'> 

end 

=> 

<T  1  at  >  *  m(T,  com,  TG) 

end 

=> 

<T  1  farf>  *  m(T,  passed,  TG) 

end 

=> 

D(cl  *  c2) 

end 

=> 

Go(<TG  1  x>)  *  Go(<T  1  y>) 

end 

=> 

D(<TGIx>) 

end 

=> 

D(<T  1  farf>) 

end 

=> 

D(<T  1  t_far(n-l)  &  s>)  if  n  >  0 

end 

=> 

[n-l]Go(cf)  ifn>0 

end 
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The  Elan  implementation  allows  us  to  execute  the  specification.  We  have  tested  the  railroad  crossing  specification  sys¬ 
tematically  for  inputs  ranging  from  0  to  15  minutes  (of  railroad  crossing  system  time)  starting  from  the  initial  configuration. 
For  example,  we  have  rewritten  the  term:  [15]  D(<T  I  fari>  *  <TG  I  upl>).  The  execution  time  was  0.380  seconds.  Elan 
provides  a  possibility  to  trace  the  rewriting.  By  analyzing  the  execution  trace  we  have  observed  that  the  specification,  as  it 
stands,  does  not  prohibit  racing  between  messages  m,.^  and  mpassed,  since  the  second  message  can  be  read  before  the  first 
one.  This  is  due  to  the  fact  that  there  are  no  time  constraints  on  the  train  speed.  The  train  may  reach  the  gate  in  0-time  before 
mcom  will  be  read.  This  will  not  happen  if  we  ensure  that  the  train  moves  with  a  bounded  speed  and  therefore  reaches  the 
train  gate  after  a  specified  time  elapse;  a  requirement  like  this  may  be  specified  by  another  timer. 

The  Elan  implementation  provides  also  more  sophisticated  facilities  for  executing  specifications  using  the  built-in  strat¬ 
egy  language  one  may  specify  complex  search  algorithms  such  as  depth  first  search,  or  constrain  the  rewriting.  In  the  future 
work  we  are  going  to  use  it  for  automatically  checking  simple  temporal  properties  of  the  specified  systems. 
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Abstract 

In  this  paper,  we  demonstrate  the  capability  of  MASS,  a  real-time  design  language,  for  large  systems 
specification.  The  paper  presents  a  hierarchical  specification  of  an  automatic  cruise  controller  that  evolves 
through  stepwise  refinement.  In  particular,  we  show  modular  desip,  the  separation  of  the  function 
and  reactive  concerns,  and  the  succinct  and  intuitive  nature  of  specifications  in  MASS. 


1  Introduction 

A  real-time  system  consists  of  a  plant  where  dynamic  processes  take  place,  and  a  controller  (an  embedded 
computer)  aimed  at  the  stabilization  of  the  on-going  processes  at  a  required  state.  The  controller  design 
is  especially  complex,  as  compared  with  non-real-time  applications,  due  to  the  reactive  aspect  of  the  l  s 
operation.  This  aspect  comprises  the  need  to  synchronize  its  computations  with  the  occurrences  of  the  p  an 
events  (indicated  by  sensor  data)  and  to  accomplish  their  executions  within  hard  deadlines  determined  by 
the  controlled  process  dynamics  (typical  applications  handle  a  large  number  of  asynchronous  events  thus 
giving  rise  to  many  intricate  scenarios).  On  the  other  hand,  real-time  systems  are  usually  safety-critical,  and 

therefore  their  correctness  is  of  an  essential  importance.  -ex-  ii,.. 

MASS,  the  real-time  design  language  employed  in  this  paper,  is  based  on  a  specification  approach  that 
handles  the  inherent  complexity  of  real-time  systems  by  completely  separating  the  concerns  of  the  funct 
and  the  reactive  aspects  in  their  specification.  However,  the  underlying  model  formally  relates  these  aspects 
in  a  way  that  enables  comprehensive  reasoning  about  the  system  behavior. 

The  key  idea  of  the  separation  paradigm  is  to  represent  events  and  functions  as  Afferent  aspects  of  a 
single  entity,  called  a  task.  In  the  functional  view,  a  task  denotes  a  computation  that  does  not 
during  execution  with  its  environment  (other  tasks,  or  external  systems).  In  the  reactive  view,  ataskis 
considered  as  a  basic  event  that  occurs  at  every  termination  of  the  task  computation  ^en^re“10“ 
(constructed  from  basic  events)  are  used  to  specify  the  activation  of  the  tasks  computations.  Hence  due  o 
the  identification  of  events  with  task  terminations,  the  specification  of  the  computation  of  each  task  (gi 
in  the  functional  part)  is  completely  independent  of  the  reactive  behavior  in  which  it 13  .  t 

MASS1  employs  a  single  specification  construct,  called  a  reaction,  that  expresses  an  activation  requiremen 
for  a  task’s  computation  in  response  to  events  (namely,  terminations  of  tasks’  co^mputa^ 
the  requirement  “every  occurrence  of  p  triggers  the  computation  associated  with  q  that  must  termma 
within  5  time  units”  is  succinctly  expressed  in  MASS  by  the  reaction:  b  =>  9  <  #•  ^1^°* 

unique  mechanism  that  enables  hierarchical  specification  of  large  systems  by  stepwise  refinement 

A  MASS  specification  is  made  executable  by  a  translation  into  a  regular  expression  over  signals  denotmg 
task  activations  and  terminations.  Operationally,  we  construct  an  automaton  that  operates  synchronously 

•Supported  in  part  by  grants  from  the  Israel  Science  Foundation,  the  German-Israeli  Foundation  for  Scientific  Research  and 

Specification’,  a  metaphor  suggesting  the  separation  of  the  activation 

mechanism  from  the  activated  puppets. 
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iarge-scal.  system  have  been  specified  and  implementing  mass’mj”  d'V'I<,pn,en*  Ipd"dt  »™»°“ 

logic  PLOT,  and  vetffi<teMofpro^mM°thS™S<>tLfcorStn™s'o7a  d™*  W^'1‘  *1"0  ‘?v“'J's  lt'  r“>-‘ta« 
requirements  expressed  in  plot.  In  a  nutshell  PT  r>T  ;  •  a  i  ,  design  in  MASS  Wlth  respect  to  system 

expression  of  durations  and  timed  occurrences  of  events  ^h*  *  emp°^  ?gic  W  tbat  allows  the  explicit 

treated  as  a  primitive  semantic  object  plot  is  deddahl^  ^ 18  ^  notion  °f  causality>  which  is 

X* puipos,'  “ 

mtblhe  operattonal  mterpretation  in  the  sense  that  it  defines  the  same  set  of runs  M“tMl 

,  rest  of  the  paper  is  organized  as  follows.  Section  2  provides  an  overview  nfv4cc  c  „*•  0 

a  worked-out  examp, e  ota  iatge  system  specidcation  with  ^“nTs^y^” 


2  Overview  of  MASS 

Act  name  is 
Tasks 

system  task,  ... 
environment  task,  . . . 

Reactions  reaction  . . , 

TimeBase  unit 
End 

anhdQvttkS  £?Ctl0n  presents  the  tasks  tbat  comprise  the  real-time  system,  classified  into  the  environment 
not  2  J tyP?  f  °vir01Jment  .tasks  ^Present  plant  activities  that  are  observable  by  the  controller  but  are 

of  its  execution^  "in  contL^th^b^h  “•*”  is  °bserVed  °nly  ^  sens“g  the  terminations 

by  the  rlac  ions  tLT  T’  ’  iS  fuUy  C°ntr°lled  *  the  Stroller  as  specified 

Dy  the  reactions.  The  Reactions  section  specifies  the  activation  requirements  for  the  system  tasks  and  th* 

Tunebase  section  defines  the  sampling  rate  of  the  controller  operation.  *  ’  ^ 

narlrr^T  a  functional  notation  of  the  form:  task-id  :  Input  ->  Output  where  task-id  is  a 

name,  and  Input  and  Output  are  finite  domains.  We  use  the  term  void  to  denote  a  singletl  However  dec 

fthC  f°rm  q:V°'d~>(?UtpUt  and  t>:void->void  «e  usually  abbreviated  to  q:->Out  and  q  respectively 

the  %Z. a  70i<1  “put  dom“'  -  il  lu™  *°  be «- — £ 

of  aEt2k  q4  -  voidTttutl  Wit*  a  t  °*hfC™Dts>  *  =  v  wkere  ®  ranges  over  the  output  domain  (in  case 

o  -  v  denl,sTh  UtPUt  t  r  ^  basic  event  is  also  denoted  by  q).  Each  occurrence  of  an  event 
9  ~,^,d  t  tbe  teraunation  of  an  execution  of  q  that  returned  the  output  value  v 

startun  nT*  t0  *  ^  &Ct  “*  the  basic  events  derived  from  tbe  act  tasks,  the  time  events: 

aldgkati.  ^  event  expression  of  the  form:  ta,  aVft  a;/3,  a^q  where  a,/3  are  events, 

■The  semantic  domain  for  MASS  is  a  real-time  systems  model  represented  by  timed-state  sentiences  We 

SSL?£  m'rnt\  te °f.r  »  observable  al»g  S  2 

a  il!l  5(oS5  ?  ”l  »f  ”**•  C<  considered  its  causes.  A  tmee  of  q  is 

t  and  was  art;"  il  .  ■  Each  element  (a, ,)  c  tr,{t)  indicates  an  execution  of  q  that  terminated  at 

t  and  was  activated  due  to  an  occurrence  of  the  cause  o  at  the  time  instant  t-i(  a  trace  value  tr  (i\  -  0 
means  that  no  execution  of  q  terminated  at  t).  K  q{  )  ~  0 
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<—  a  -M-  (3  -> 


Figure  1:  Illustration  of  mass  events 

A  trace  represents  a  possible  behavior  of  a  task*  A  behavior  of  the  entire  system,  called  a  run,  consists 
of  a  trace  for  every  task.  Note  that  fixing  the  values  of  a  trace  as  sets  means  that  we  allow  concurrent 
executions  of  the  task’s  computation,  with  the  possibility  that  some  of  them  terminate  simultaneously  (they 
are  distinguished,  however,  by  the  causes  and  the  activation  times). 

Events  are  interpreted  over  closed  time  intervals  (including  singletons  [n,  n]  representing  time  instants) 
with  respect  to  a  given  run.  Informally  (see  Fig.  1): 

,  •  A  basic  event  occurs  at  every  time  instant  t  such  that  trq(t)  ^  0. 

•  a  q  occurs  together  with  those  occurrences  of  q  that  were  caused  by  a  (namely,  at  the  time  instants 
t  such  that  there  exists  an  element  (a,i)  €  trq(t)), 

•  startup  occurs  only  at  the  instant  the  system  starts  operating,  0  occurs  at  every  time  instant,  1  occurs 
at  every  unit  interval  [n,n+ 1],  and  *  occurs  on  every  time  interval  (specifying  an  arbitrary  duration). 

•  The  logical  symbols  V  are  denote  negation,  and  disjunction,  respectively. 

•  The  symbol  ;  is  the  standard  chop  operator  of  interval  temporal  logic.  The  event  a;/3  occurs  at  any 
interval  composed  of  an  occurrence  of  a  immediately  followed  by  an  occurrence  of  (3. 

The  standard  temporal  operator  “eventually”  is  defined  by  O a  ==  (*;  a;  *),  its  dual  “always”  by  Oa  =f  -»0 -»a, 
and  the  “next”  operator  by  Oa  ==  1; a- 

A  reaction  describes  an  activation  requirement  for  a  system  task  by  an  expression  of  the  form: 

[activating- event  =>  response-tasQ  :  aborting- event  <  deadline . 

The  activating  and  aborting  events  are  normal  event  expressions,  the  response-task  is  the  name  of  a  system 
task  declared  in  the  act,  and  the  deadline  is  a  time  expression.  The  activating  event  must  be  explicitly 
specified  in  a  reaction,  and  is  considered  a  cause  of  the  response  task  in  the  real-time  model  for  MASS  events. 
In  contrast,  the  aborting  event  and  the  deadline  are  both  optional. 

The  intended  meaning  of  a  reaction  is  that  the  response  task  has  to  be  activated  following  each  occurrence 
of  the  activating  event,  and  the  termination  of  its  execution  must  be  observed  within  the  duration  designated 
by  the  deadline.  However,  MASS  tasks  are  not  executed  instantaneously  and  therefore  the  termination  of  the 
response  task  cannot  be  observed  but  strictly  after  the  occurrence  of  the  activating  event.  A  task  terminates 
normally  if  its  execution  is  completed  no  later  than  the  first  occurrence  of  the  aborting  event.  Otherwise,  the 
task  execution  is  aborted  at  the  occurrence  of  the  aborting  event,  returning  the  value  If  an  execution 
exceeds  the  deadline,  the  system  fails  (the  actual  implementation  of  a  system  failure  is  left  as  a  design 
decision). 

For  example,  consider  the  reaction  [  TrainOut  =>  GateOpen  ]  :Trainln  <10sec  where  Trainln  and  TrainOut 
are  environment  tasks  that  indicate;  respectively,  the  entrance  and  exit  of  a  train  in  a  railroad  crossing,  and 
the  task  GateOpen  denotes  the  function  that  moves  the  gate  up.  The  meaning  of  this  reaction  is  that 
upon  each  occurrence  of  the  event  TrainOut,  the  task  GateOpen  should  be  activated,  and  its  execution  must 
be  completed  within  10. seconds.  However,  the  execution  of  GateOpen  is  aborted,  generating  the  event 
GateOpen=!,  if  the  event  Trainln  occurs  while  the  gate  is  opening. 
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interpretation  of  tire  e»mr'l”.'C(5erSioSIlj*tUs  ' Vs”11  tv.  “"d  “  a  c0“r'te  measure  for  tire 

execution  environment  (see  below).PThus  it  determine,  tv  '’  ifV‘  tt,'  “mp  ing  rat'  of  ‘he  synchronous 
therefore  it  affects  the  Lent  to  2hi^^£"^“  ",tet  “  b'  *™ 

practice*  the^e^lai^j^essior^^runsformed^ntoa'finite^automatontlf  t  *  *  b 

and  reacts  synchronously  by  activation  and Xtiotof s^Tm ST ™ ,b' 

consists  of  a  reactive  executive  and  a  functions  executive  tv  t  *  Tt  ,' ent“e  executlon  environment 

execution  of  the  activated  functions,  respectively  ™  ““CUII“U)r  U“  ^automaton  and  the 

to  53“  f each  time  instant  *■ the  ^ 

Period  [*_»,*).  Terminations  of  environment  task^are  reJorteH  h  terminated  *  the 

termination  is  reported  by  the  functions  executive  The  *,  t  /  6  sensors-  For  system  tasks,  the 

to  identify  occurrences  ofactiva  wZ  a  auto?laton  evaluates  the  observation  set  in  order 

generates  activation  and  abortion  commands  “*’*  rcactions>  and  respectively 

sTcUonj1  “!!ed  ^  (•>“  declared  within  the  Tasks 

previously  defined  tasks  A  virTuI? t  aiC  Wlth  °CCurrences  of  events  generated  by  other, 

Lcutionsofthe  t^sedtodSL^ “■“**-  “!*  ** 

of  activating  and  aborting  events.  The  basic  form  of  •  l  i  f  ^a_ta*k  caf  used  onty  in  specifications 
virtual  task  name  and  a  is  a  mass  event  (called  the  markin^event).  eC  aratl°n  13  v  at  Q  where  v  is  the 


2.1 


EverylOOms  at  startup  V  (EverylOOmsjlOOms) 
Modularity:  Refinement,  Composition,  and  Plays 


*  7”b"  0'tbsl“CtiOT  «*  of  which  adds  design 

mechanisms  that  enahie  a  hierarchical  modular  r^taZ 

*  talh^nedfic °  *»v  "i,b act  ,hf  ‘  "  its  implementation  (concrete  examples 

.ft?er^r:r“tr^s 

•  A  Composition  is  a  representation  of  a  task  q  by  a  of  acts  Au . . . ,  Ak,  expressed  as: 

Act  9is  (Ai||...||A*)  End 

decWiifine^ct  mavt  b,'“ra',active  ^taneously  with  each  activation  of  A  system  task 

acts  to  react T  ,k  y,b  ‘‘“’"'f  f  “  “™“ment  task  in  any  of  the  other  acts,  enabling  these 
acts  to  react  to  the  events  generated  by  that  task.  ® 

Task  refinement  and  composition  enable  a  hierarchical  modular  construction  of  a  system  The  nrm« 
start,  with  an  act  specifying  the  operation  of  the  system  at  a  toyvlevel  Zr  ihen.  system  X  aTe 
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separately  refined  by  (a  composition  of)  acts  that  elaborate  their  operations  in  terms  of  lower  level  tasks. 
The  process  can  be  iteratively  applied  to  tasks  in  lower  levels  until  all  system  tasks  are  represented  by 
functional  computations.  A  set  of  acts  that  establish  a  hierarchical  structure  of  refinements  is  called  a  play. 


3  Specifying  Large  Systems  with  MASS 

In  this  section,  we  demonstrate  the  applicability  of  MASS  to  the  specification  of  large  real-time  systems. 
We  present  the  specification  of  a  cruise-control  system  that  evolves  through  iterative  hierarchical  system 
refinement.  This  example  is  extensively  worked  out  in  the  literature  to  demonstrate  real-time  specification 
frameworks  (see  Shaw  [8]  for  survey).  Thus,  it  is  possible  to  compare  MASS  with  other  approaches. 


3.1  Automatic  Cruise  Control 

The  Automatic  Cruise  Control  (ACC)  is  intended  to  control  the  speed  of  a  car  according  to  the  driver’s 
instructions.  The  interface  with  the  driver  consists  of  a  master  switch  (on/off),  a  3-state  speed-command 
lever  (decrease,  maintain,  increase),  a  resume  button,  and  the  gas  and  brake  pedals.  The  ACC  t  es  over 
the  speed  control  whenever  the  master  switch  is  turned  on,  provided  the  car  engine  is  working.  The  control 
is  released  either  if  the  engine  goes  off,  or  the  master  switch  is  turned  off.  . 

While  active,  the  ACC  operates  to  maintain  the  car  speed.  The  driver  may  instruct  the  system  to  increas 
or  decrease  the  maintained  speed  by  holding  the  speed-command  lever  at  the  corresponding  position l  until 
the  required  speed  is  attained.  The  control  operation  is  immediately  suspended  in  case  either  the  brake  or 
the  gl  pedal  are  pressed.  In  this  case,  the  driver  may  return  control  to  th^^CC^y  prefmg/^  r™ 
button  (in  which  case  the  ACC  returns  to  maintain  the  suspended  speed,  provided  the  brake  and  gas  pedals 

are  not  pressed). 

3.2  Hierarchical  System  Refinement 

The  specification  of  the  ACC  system  is  developed  through  iterative  hierarchical  system  refin"menL  This 
method  suggests  to  start  a  large  system  specification  by  refining  the  main  thread  of  the  system  ' 

Everything  else,  though  known  to  be  part  of  the  system,  is  considered  part  of  the  environment.  In  feeding 
iterations,  the  structure  is  broadened  by  transferring  environment  activities  into  ^ 

their  behaviors.  At  any  stage  of  the  development  the  specification  is  amenable  to  simulation  where  the 

unspecified  behavior  is  considered  to  be  part  of  the  environment.  nartition  into 

In  a  development  step,  a  task  is  refined  either  into  a  composition  of  tasks  that  represents  a  partition  mt 
concurrent  activities,  or  by  an  act  that  specifies  its  design  in  terms' of  lower-level  activities,  also  represented 

^  In  the  case  of  refinement  by  composition,  we  can  independently  proceed  with  any  one  of  the ■  ~“^uent 
tasks  However,  the  partition  of  a  composition  need  not  specify  all  the  constituents  in  order  to  be  able  to 
proceed  with  a  refinement  of  a  certain  task  in  the  composition.  This  is  possible,  since 111  “  ^  ^  w^le 
we  make  no  assumption  regarding  the  source  of  an  environment  task;  whether  it  is  external  to  the  wM 
system,  or  a  system  task  in  another  act  of  the  play.  Thus  one  may  declare  environment  tasks^  lmown 
part  of  another  subsystem,  even  though  the  corresponding  act  has  not  been  specified  .^Srf^tute 
of  task  refinement  by  an  act,  one  may  proceed  with  the  refinement  of  any  of  the  system  tasks  t 

the  act  independently  of  the  refinement  of  other  system  tasks. 

A  refinement  iteration  may  be  taken  to  any  desired  extent  yielding  a  complete  specification  m 
that  no  assumptions  are  made  regarding  unrefined  tasks.  In  further  iterations  we  go  over  spe^  °  e 
level  and  either  expand  unrefined  system  tasks,  or  extend  a  composition  with  new  acts  that ^specif}  t 
behavior  of  tasks  that  were,  until  now,  considered  part  of  the  environment.  We  proceed  with  p 

until  all  system  tasks  are  decomposed  into  basic  components. 

In  the  following  subsections,  this  method  is  'illustrated  by  working  out  the  specification  of  the  ACC. 
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Figure  2:  Main  control-thread  of  ACC 


3.3  Main  Tread  Specification 


m't  th".ad  0f  tke  ——  (Fig.  2). 

u*  CruiseCrl,  according  lo  *— •  *-l  * 

Act  ACC-Control  is 
Tasks 


environment 

system 

virtual 

Reactions 


Engine:— ^{ofF,  on},  DriverCmd:->{start,  stop} 

CruiseCrl 

EngineOn  at  (Engine=on;-iOEngine=ofF) 


[  DriverCmd=start  A  EngineOn  =>  CruiseCrl  ]:  Engine=ofrvDriverCmd=stop 


moritoref tLt£e  not  **>  «*  *l«r  command,  and  the  engine  state  are 

Utee  stage  £J  "  *  *  “  *  *  8 

The  task  CruiseCrl  is  further  refined  as  follows. 


Act  CruiseCrl 
Tasks 

environment  Brakes,  Gas,  Resume 
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system  ActiveCrl 
virtual 

Suspend  at  (CruiseCmd;first(Brakes  V  Gas)), 

CruiseCmd  at  (startupV  ((Suspend;first(ResumeA->Brakes)) 

Reactions  [  CruiseCmd  =>  ActiveCrl  ]  :Suspend 

End 

first(a)  is  defined  by  (*;a)A-iO(a;  1) ,  indicating  an  interval  that  ends  with  the  first  occurrence  of  a. 

The  virtual  task  Suspend  designates  the  transition  from  active  to  suspended  control  (due  to  gas  or  brake 
pedal  press,  represented  by  the  environment  tasks  Brakes  and  Gas).  The  virtual  task  CruiseCmd  designates 
the  transition  to  active  control,  either  at  startup  or  due  to  a  press  of  the  resume  button  (represented  by  the 
environment  task  Resume)  in  a  suspended  state  while  the  brakes  are  not  pressed.  The  task  ActiveCrl  denotes 
the  ACC  active  control  operation. 


Next  we  refine  ActiveCrl  as  follows. 

Act  ActiveCrl 
Tasks 

environment  Decrease,  Maintain,  Increase 
system  MaintainSpeed,  DecreaseSpeed,  IncreaseSpeed 
Reactions 

[  (startup  V  Maintain)  =>  MaintainSpeed  ]  :Decrease  V  Increase 
[  Decrease  =>  DecreaseSpeed  ]  : Maintain 
[  Increase  =>  IncreaseSpeed  ]  ‘.Maintain 
End 


The  environment  tasks  Increase,  Decrease,  and  Maintain  designate  the  corresponding  changes*  in  the  lever 
position,  and  the  task  CurrentSpeed  provides  the  car  speed  at  every  time  instant  (it  is  the  same  task  as 
declared  in  CruiseCrl).  The  system  tasks  MaintainSpeed,  DecreaseSpeed,  IncreaseSpeed  implement  the  control 
operations  corresponding  to  the  current  lever  position. 

The  concrete  behavior  of  the  control  operations  is  given  by  the  refinements  below.  The  act  MaintainSpeed 
operates  a  control-loop,  at  10Hz  rate,  2  to  maintain  the  car  speed  as  recorded  at  the  act  activation  (the  first 
reaction). 


Act  MaintainSpeed 
Tasks 

system  SpeedControl,  ReadSpeed 
Reactions 

[  startup  =>  ReadSpeed  ]  <70ms 
[  EverylOOms  =>  SpeedControl  ]  <20ms 
End 


The  acts,  DecreaseSpeed  and  IncreaseSpeed  operate  to 
throttle  up  and  down,  respectively,  in  an  open  loop. 

Act  DecreaseSpeed 
Tasks 

system  RetractThrottle 
Reactions 

[  EverylOOms  =>  RetractThrottle  ]  <20ms 
End 


increase  and  decrease  the  car  speed  by  moving  the 

Act  IncreaseSpeed 
Tasks 

system  Adva  nceThrottle 
Reactions 

[  EverylOOms  =>  AdvanceThrottle  ]  <20ms 


3 Events  designating  periodic  signals  are  not  explicitly  declared  in  acts.  They  arc  assumed  to  be  pre-defined  by  virtual  tasks. 
For  instance,  a  1Hz  signal  is  defined  by  Everylsec  at  startup  V  (EveryXsec;lsec). 
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rcCqUirements  (namely- the  ^"i  tasks  can  not  be  further  refined) 
Hence,  the  main  thread  of  the  system  refinement  has  been  completed  In  the  next  section  a  -u  u.  ' 

next  iteration  where  the  play  is  completed  with  horizontal  (composition)  acts  ’  the 


3.4  Completion  of  the  Play 

At  this  stage,  after  the  main  thread  of  the  system  operation  had  been  specified,  we  elaborate  declarations 
of  environment  taAs,  mid  combine  them  into  the  entire  system  specification.  At  the  top  levdofthespecifc 
cation,  we  define  the  acts  EngineMon,  DriverCmdMon,  and  SpeedMon.  P 

■The  act  DnverCmdMon  encapsulates  the  master-switch  that  turns  the  ACC  on  and  off  This  act  is 
responsible  for  generating  the  events  denoted  by  DriverCmd  (used  by  the  act  ACC-Control). 

Act  DriverCmdMon 
Tasks 


End 


environment  MasterSwOfF,  MasterSwOn 
virtual  DriverCmd:-)^  start,  stop  } 

where  DriverCmd=start  at  (0.2sec;MasterSwOn) 
DriverCmd=stop  at  MasterSwOfF 


The  environment  tasks  MasterSwOfF  and  MasterSwOn  represent  hardware  interrupts  generated  upon  turning 

SrS:  respectively.  DriverCmd  is  declared  as  a  virtual  task  considered  an  abstraction 

oneri  ™  •  N  j  2?  !Ty  ^  “inlands  that  occur  within  the  first  0.2  seconds  of  the  system 

!Sow  A  lgn°r,  ;•  S?elay!  alth°U?h  n0t  specified  in  the  ACC  requirements,  is  necessary  in  order  to 
allow  speed  computation  and  engine  monitoring  prior  to  entering  the  active-control  state. 

.  .  JhlS  af  “  SUperfl1U0,us  since  we  could  directly  use  MasterSwOfF  and  MasterSwOn  in  ACC-Control.  However 
mokmen  lf  ff  '  “^““development  and  maintenance,  it  is  good  design  practice  to  hide  the  specific 
implementation  of  the  sensor.  For  instance,  in  a  later  stage  of  the  development,  we  could  decide  to  modify 

not  S“"thm3S S :Sm  “"rUP‘S  <S”  W°")-  Witt  ““  SU6geS,'d  <‘“igD' tUs  ’">Uld 

Act  EngineMon 
Tasks 


system  EngineState:->{  oFF,  on  } 
virtual  Engine:->{  ofF,  on  } 

where  Engine=oFF  at  Startup  V  (Engine=on;first(EngineState=oFF)) 
Engine=on  at  (Engine=ofF;first(EngineState=on) 

Reactions  [  Every20ms  =>  EngineState  1  <  10ms 
End 


Here,  we  prefer  an  implementation  by  polling  (mentioned  above).  The  task  EngineState  periodically  samples 

the  state  of  the  engine,  and  Engine  is  declared  as  a  virtual  task  that  designates  the  changes  in  the  state  of 
the  engine  operation. 

follows0^"  t0  COmP°Se  the  additional  acts  riOi  ACC-Control  we  add  an  upper  level  act,  ACC,  declared  as 

Act  ACC  is  (  ACC-Control  ||  DriverCmdMon  ||  EngineMon  )  End. 

At  the  next  level,  we  define  the  acts  BrakesMon,  GasMo„  and  ResumeMon  that  encapsulate,  respectively, 
the  events  Brakes,  Gas  and  Resume.  We  assume  that  these  events  are  generated  by  interrupts,  hence  the  acts 
are  very  simple  (similar  to  DriverCmdMon). 
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However,  the  composition  of  these  acts  into  the  play  turns  out  to  be  somewhat  tedious.  Normally,  we 
would  need  to  rename  the  act  CruiseCrl,  say  by  MainCruiseCrl,  and  then  introduce  the  definition 

Act  CruiseCrl  is  (  MainCruiseCrl  ||  BrakesMon  ||  GasMon  ||  ResumeMon  )  End. 

This  procedure  is  undesirable  for  a  number  of  reasons. 

•  It  enforces  modifications  of  already  existing  part  of  the  specification. 

•  It  inflates  the  play  with  superfluous  hierarchical  levels  (not  contributing  levels  of  essential  information). 

•  It  presents  at  the  same  abstraction  level  acts  that  are  not  equally  significant  in  the  specification  of  the 
system  behavior  at  this  level.  Such  a  presentation  seems  unnatural,  and  blurs  the  picture. 

Therefore,  we  allow  naming  a  composition  by  one  of  the  constituent  act.  This  form  emphasizes  the  subsystem 
which  seems  to  be  central  (in  the  developer’s  view),  and  does  not  force  a  designer  to  have  a  complete  view 
of  the  system  structure  at  the  initial  stage. 

Thus,  in  our  case,  we  define  the  composition 

Act  CruiseCrl  is  (  CruiseCrl  ||  BrakesMon  ||  GasMon  ||  ResumeMon  )  End. 

Finally,  we  define  the  act  LeverMon  that  generates  the  events  Decrease,  Maintain,  and  Increase,  which 
indicate  the  corresponding  transitions  in  the  lever  positions.  The  implementation  of  this  act  relies  on 
periodic  sampling  of  the  lever  and  identification  of  the  state  transitions  by  virtual  tasks. 

Act  LeverMon 
Tasks 

system  Lever  Position  :—>■{  down,  mid,  up  } 
virtual 

Maintain  at  startupV  ((Increase  V  Decrease);first(LeverPosition=mid)), 

Increase  at  (Maintain;first(LeverPosition=up)), 

Decrease  at  (Maintain;first(LeverPosition=down)) 

Reactions  [  Every200ms  =>  LeverPosition  ]  <  10ms 
End 

Here,  again,  we  employ  the  relaxed  form  of  composition,  and  define 

Act  ActiveCrl  is  (  ActiveCrl  ||  LeverMon  )  End. 


4  Related  Work  and  Discussion 

MASS  is  a  synchronous  language  that  monitors  the  execution  of  asynchronous  computations  under  real¬ 
time  constraints.  This  execution  paradigm,  which  overcomes  the  essential  limitation  of  infinitesimally  short 
computations  assumed  by  the  synchronous  model  [1],  is  enabled  by  the  idea  of  identifying  system  events 
with  the  terminations  of  the  computations. 

CRP  introduced  by  Berry  et  al.  [3]  presents  an  alternative  approach.  The  language  extends  Estekel  [2] 
with  a  special  construct,  exec  L:P,  which  implicitly  associates  the  label  L  with  the  events  (signals)  denoting 
the  start,  termination,  and  abortion  of  an  execution  of  P.  This  approach  is  inherently  restricted  since  once 
engaged  with  an  execution,  a  program  cannot  respond  to  additional  activations.  For  instance,  if  P  is  an 
asynchronous  computation,  a  requirement  like  “activate  P  upon  every  occurrence  of  the  event  a”  is  not 
expressible  in  this  formalism. 

Synchronous  JS?/eZ (previously  called  Embedded  Eifel  [4])  employs  an  execution  environment  similar  to 
mass,  but  without  monitoring  asynchronous  computations.  The  reactive  behavior  is  specified  in  the  syn¬ 
chronous  language  Esterel,  augmented  with  a  special  construct  schedule(f)  where  f  is  a  function.  Functions 
scheduled  this  way,  called  background  services,  are  run  asynchronously  (in  a  non-preemptive  manner)  in  the 
time  slots  between  the  termination  of  the  synchronous  computations  and  the  next  time  instant,  with  no 
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deadlines.  A  background  service  can  communicate  with  the  reactive  part  by  a  special  command  that  adds  a 
signal  to  the  next  time  instant. 

.  cMa^  “  “  «ecutable  language  in  the  full  operational  sense.  A  similar  approach  is  also  taken  in  the  design 
o  S  FE  [6J,  which  is  a  procedural  real-time  programming  language  with  interval  temporal-logic  semantics 
(however,  SAFE  does  not  support  concurrency). 


5  Conclusion 

The  main  contribution  of  the  plot/mass  framework  is  the  idea  of  associating  each  primitive  event  in  a 
real-time  system  with  a  concrete  function,  and  interpreting  every  termination  of  the  function  execution  as 
an  occurrence  of  the  event.  This  idea  gives  rise  to  a  real-time  specification  framework  that  enables  the  design 

of  real-time  systems,  and  formal  reasoning  about  the  behavior  of  asynchronous  functions  whose  executions 
are  controlled  synchronously. 

mass,  introduces  a  new  declarative  activation-oriented  specification  approach,  which  we  believe  is  natural 
for  real-time  system  representation,  and  easy  for  system  designers  to  understand  and  use.  Another  novelty 
of  mass  is  the  concept  of  activation  refinement,  which  provides  an  essential  means  for  modular  development 
and  reasoning. 

Finally,  the  fact  that  events  and  computations  are  semantically  related  provides  for  a  complete  separation 

of  the  specification  of  the  reactive  and  algorithmic  aspects  of  a  system,  an  important  software-engineering 
concern.  "  ° 
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Abstract 

To  engineer  reliable  real-time  systems,  it  is  desirable  to  discover  timing  anomalies  early  in  the  development  process.  How¬ 
ever,  there  is  little  work  addressing  the  problem  of  accurately  predicting  timing  properties  of  real-time  systems  before  im¬ 
plementations  are  developed.  This  paper  describes  an  approach  to  the  specification  and  analysis  of  scheduling  problems  of 
real-time  systems.  The  method  is  based  on  ACSR-VP,  which  is  an  extension  of  ACSR,  a  real-time  process  algebra,  with 
value-passing  capabilities.  Combined  with  the  existing  features  of  ACSR  for  representing  time,  synchronization  and  resource 
requirements,  ACSR-VP  can  be  used  to  describe  an  instance  of  a  scheduling  problem  as  a  process  that  has  parameters  of  the 
problem  as  free  variables.  The  specification  is  analyzed  by  means  of  a  symbolic  algorithm.  The  outcome  of  the  analysis  is  a  set 
of  equations  and  a  solution  to  which  yields  the  values  of  the  parameters  that  make  the  system  schedulable.  These  equations  can 
be  solved  using  integer  programming  or  constraint  logic  programming.  The  paper  presents  the  theory  of  ACSR-VP  briefly  and 
an  example  of  the  period  assignment  problem  for  rate-monotonic  scheduling.  We  also  explain  our  current  tool  implementation 
effort  and  plan  for  incorporating  it  into  the  existing  toolset,  PARAGON. 


1  Introduction 

The  desire  to  automate  or  incorporate  intelligent  controllers  into  control  systems  has  lead  to  rapid  growth  in  the  demand  for 
real-time  software  systems.  Moreover,  these  systems  are  becoming  increasingly  complex  and  require  careful  design  analysis 
to  ensure  reliability  before  implementation.  Recently,  there  has  been  much  work  on  formal  methods  for  the  specification  and 
analysis  of  real-time  systems  [8,  12],  Most  of  the  work  assumes  that  various  real-time  systems  attributes,  such  as  execution 
time,  release  time,  priorities,  etc.,  are  fixed  a  priori  and  the  goal  is  to  determine  whether  a  system  with  all  these  known  attributes 
would  meet  required  safety  properties.  One  example  of  safety  property  is  schedulability  analysis;  that  is,  to  determine  whether 
or  not  a  given  set  of  real-time  tasks  under  a  particular  scheduling  discipline  can  meet  all  of  its  timing  constraints. 

The  pioneering  work  by  Liu  and  Layland  [17]  derives  schedulability  conditions  for  rate-monotonic  scheduling  and  earliest- 
deadline-first  scheduling.  Since  then,  much  work  on  schedulability  analysis  has  been  done  which  includes  various  extensions 
of  these  results  [11,  28,  25, 4,  26, 22,  18, 3).  Each  of  these  extensions  expands  the  applicability  of  schedulability  analysis  to 
real-time  task  models  with  different  assumptions.  In  particular,  there  has  been  much  advance  in  scheduling  theory  to  address 
uncertain  nature  of  timing  attributes  at  the  design  phase  of  a  real-time  system.  This  problem  is  complicated  because  it  is  not 
sufficient  to  consider  the  worst  case  timing  values  for  schedulability  analysis.  For  example,  scheduling  anomalies  can  occur 
even  when  there  is  only  one  processor  and  jobs  have  variable  execution  times  and  are  nonpreemptable.  Also  for  preemptable 
jobs  with  one  processor,  scheduling  anomalies  can  occur  when  jobs  have  arbitrary  release  times  and  share  resources.  These 
scheduling  anomalies  make  the  problem  of  validating  a  priority-driven  system  difficult.  Clearly,  exhaustive  simulation  or  testing 
is  not  practical  in  general  except  for  small  systems  of  practical  interest.  There  have  been  many  different  heuristics  developed 
to  solve  some  of  these  general  schedulability  analysis  problems.  However,  each  algorithm  is  problem  specific  and  thus  when  a 
problem  is  modified,  one  has  to  develop  new  heuristics. 
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Figure  1:  Overview  of  the  Framework 


In  this  paper,  we  describe  a  framework  that  allows  one  to  model  scheduling  analysis  problems  with  variable  release  and 
execution  times  relative  timing  constraints,  precedence  relations,  dynamic  priorities,  multiprocessors  etc.  Our  approach  is 
based  on  ACSR-VP  and  symbolic  bisimulation  algorithm.  ™ 

ACSR  (Algebra  of  Communicating  Shared  Resources)  [14],  is  a  discrete  real-time  process  algebra.  ACSR  has  several 
aS  resoui;ces*  Priorities,  exceptions,  and  interrupts,  which  are  essential  in  modeling  real-time  systems 
ACSR-VP  is  an  extension  of  ACSR  with  value-passing  and  parameterized  processes  to  be  able  to  model  real-time  systems 

xm  •  !!ming  attnbute*  fnd  dynamic  priorities.  In  addition,  symbolic  bisimulation  for  ACSR-VP  has  been  defined. 
ACSR-VP  without  symbolic  bisimulation  has  been  applied  to  the  simple  schedulability  analysis  problem  [5],  by  assuming  that 
all  parameters  are  ground,  i.e.,  constants.  However,  it  is  not  possible  to  use  the  technique  described  in  [5]  to  solve  the  general 
schedulability  analysis  problem  with  unknown  timing  parameters. 

Figure  1  shows  the  overall  structure  of  our  approach.  We  specify  a  real-time  system  with  unknown  timing  or  priority 
parameters  in  ACSR-VP.  For  the  schedulability  analysis  of  the  specified  system,  we  check  symbolically  whether  or  not  it  is 
bisimilar  to  a  process  idling  forever.  The  result  is  a  set  of  predicate  equations,  which  can  be  solved  using  widely  available 
linear-programming  or  constraint-programming  techniques.  The  solution  to  the  set  of  equations  identifies,  if  exists,  under  what 
values  of  unknown  parameters  the  system  becomes  schedulable.  To  support  the  effective  use  of  the  the  symbolic  ACSR-VP 

analysis  we  are  developing  a  tool  and  planning  to  integrate  into  PARAGON  [27],  a  toolset  with  graphical  interface  to  support 
me  use  or  ALoK. 


Tte  rest  of  the  paper  is  organized  as  follows.  Sections  2  overviews  the  theory  of  the  underlying  formal  method,  ACSR- ' 
VP,  and  introduce  symbolic  bisimulation  for  ACSR-VP  expressions.  Section  3  gives  a  specification  of  a  scheduling  problem, 
™m^h*P*riodassi8nmentProblem  and  illustrates  how  to  analyze  an  instances  of  this  problem.  Section  4  briefly  describes 
the  PARAGON  toolset  and  its  support  for  value-passing  specifications,  and  outlines  the  incorporation  of  ACSR-VP  into  the 
toolset.  We  conclude  with  a  summary  and  an  outline  of  future  work  in  Section  5. 


2  ACSR-VP 


ACSR-VP  extends  the  process  algebra  ACSR  [14]  by  allowing  values  to  be  communicated  along  communication  channels.  In 
this  section  we  present  ACSR-VP  concentrating  on  its  value-passing  capabilities.  We  refer  to  the  above  papers  for  additional 
information  on  ACSR. 

We  assume  a  set  of  variables  X  ranged  over  by  x,  y,  a  set  of  values  V  ranged  over  by  v,  and  a  set  of  labels  L  ranged  over 
by  c,  a.  Moreover,  we  assume  a  set  Expr  of  expressions  (which  includes  arithmetic  expressions)  and  we  let  BExpr  C  Expr 
be  the  subset  containing  boolean  expressions.  We  let  e  and  b  range  over  Expr  and  BExpr  respectively,  and  we  write  z  for  a 
tuple  zi , ...  zn  of  syntactic  entities. 

ACSR-VP  has  two  types  of  actions:  instantaneous  communication  and  timed  resource  access.  Access  to  resources  and 
communication  channels  is  governed  by  priorities.  A  priority  expression  p  is  attached  to  every  communication  event  and 
resource  access.  A  partial  order  on  the  set  of  events  and  actions,  the  preemption  relation,  allows  one  to  model  preemption  of 
lower-priority  activities  by  higher-priority  ones. 

Instantaneous  actions,  called  events,  provide  the  basic  synchronization  and  communication  primitives  in  the  process  algebra. 
An  event  is  denoted  as  a  pair  (i,  ep)  representing  execution  of  action  i  at  priority  ep,  where  i  ranges  over  r,  the  idle  action, 
c?x,  the  input  action,  and  c!e,  the  output  action.  We  use  VE  to  denote  the  domain  of  events  and  let  A  range  over  events.  We 
use  /(A)  and  7r(A)  to  represent  the  label  and  priority,  respectively,  of  the  event  A;  e.g.,  l((c\x,p))  =  c!  and  l((c?x,p))  =  cl. 
To  model  resource  access,  we  assume  that  a  system  contains  a  finite  set  of  serially-reusable  resources  drawn  from  some  set 
R.  An  action  that  consumes  one  tick  of  time  is  drawn  from  the  domain  P(R  x  Expr)  with  the  restriction  that  each  resource 
is  represented  at  most  once.  For  example  the  singleton  action  {(r,ep)}  denotes  the  use  of  some  resource  r  €  R  at  priority 
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level  ep.  The  action  0  represents  idling  for  one  unit  of  time,  since  no  resource  is  consumed.  We  let  Vr  to  denote  the  domain 
of  timed  actions  with  A,  B,  to  range  over  VR.  We  define  p(A)  to  be  the  set  of  the  resources  used  by  action  A,  for  example 
P({(rt>Pi)>  (**2 > P2) })  =  {ri> ^2}-  We  also  use  7rr(A)  to  denote  the  priority  level  of  the  use  of  the  resource  r  in  the  action 
A;  e.g.,  flVi({(JT,Pi),(r2,P2)})  =  pi,  and  write  7rr(A)  =  0  if  r  g  p(A).  The  entire  domain  of  actions  is  denoted  by 
V  =  VRU  Ve,  and  we  let  a,  p  range  over  V.  We  let  P,  Q  range  over  ACSR-VP  processes  and  we  assume  a  set  of  process 
constants  ranged  over  by  C.  The  following  grammar  describes  the  syntax  of  ACSR-VP  processes: 

P  ::=  NIL|A:P|A.P|P  +  P|P||P| 

6  P  |  P\F  |  [P]/  |  C(x). 

In  the  input-prefixed  process  (c?x,  e).P  the  occurrences  of  variable  x  is  bound.  We  write  fv(P)  for  the  set  of  free  variables  of 

P .  Each  agent  constant  C  has  an  associated  definition  C'(x)  P  where  f v(P)  C  x  and  x  are  pairwise  distinct.  We  note  that 

in  an  input  prefix  (c?x,  e).P,  e  should  not  contain  the  bound  variable  x,  although  x  may  occur  in  P. 

An  informal  explanation  of  ACSR-VP  constructs  follows:  The  process  NIL  represents  the  inactive  process.  There  are  two 
prefix  operators,  corresponding  to  the  two  types  of  actions.  The  first,  A  :  P,  executes  a  resource-consuming  action  during  the 
first  time  unit  and  proceeds  to  process  P.  On  the  other  hand  A.  P,  executes  the  instantaneous  event  A  and  proceeds  to  P.  The 
process  P  +  Q  represents  a  nondeterministic  choice  between  the  two  summands.  The  process  P\\Q  describes  the  concurrent 
composition  of  P  and  Q :  the  component  processes  may  proceed  independently  or  interact  with  one  another  while  executing 
instantaneous  events,  and  they  synchronize  on  timed  actions.  Process  b  -J-  P  represents  the  conditional  process:  it  performs  as 
P  if  boolean  expression  b  evaluates  to  true  and  as  NIL  otherwise.  In  P\F,  where  F  CL,  the  scope  of  labels  in  F  is  restricted 
to  process  P:  components  of  P  may  use  these  labels  to  interact  with  one  another  but  not  with  P’s  environment.  The  construct 
[•P]/.  I QR,  produces  a  process  that  reserves  the  use  of  resources  in  I  for  itself,  extending  every  action  A  in  P  with  resources 
in  I  -  p(A)  at  priority  0. 

The  semantics  of  ACSR-VP  processes  may  be  provided  as  a  labeled  transition  system,  similarly  to  that  of  ACSR.  It  ad¬ 
ditionally  makes  use  of  the  following  ideas:  Process  (c!ei,e2).P  transmits  the  value  obtained  by  evaluating  expression  ei 
along  channel  c,  with  priority  the  value  of  expression  e2,  and  then  behaves  like  P.  Process  (c?x,p).P  receives  a  value  v  from 
communication  channel  c  and  then  behaves  like  P[v/x],  that  is  P  with  v  substituted  for  variable  x.  In  the  concurrent  composi¬ 
tion  (c?s,pi).Pi||(dv,p2).P2,  the  two  components  of  the  parallel  composition  may  synchronize  with  each  other  on  channel  c 
resulting  in  the  transmission  of  value  v  and  producing  an  event  (r,pi  +P2). 

2.1  Unprioritized  Symbolic  Graphs  with  Assignment 

Consider  the  simple  ACSR-VP  process  P  d=f  (in?x,  l).(out!x,  1).NIL  that  receives  a  value  along  channel  in  and  then  outputs 
it  on  channel  out,  and  where  x  ranges  over  integers.  According  to  traditional  methods  for  providing  semantic  models  for 
concurrent  processes,  using  transition  graphs,  process  P  in  infinite  branching,  as  it  can  engage  in  the  transition  (in?n,  1)  for 
every  integer  n.  As  a  result  standard  techniques  for  analysis  and  verification  cannot  be  applied  to  such  processes. 

Several  approaches  have  been  proposed  to  deal  with  this  problem  for  various  subclasses  of  value-passing  processes  [9, 16, 
20, 13].  One  of  these  advocates  the  use  of  symbolic  semantics  for  providing  finite  representations  of  value-passing  processes. 
This  is  achieved  by  taking  a  more  conceptual  view  of  value-passing  than  the  one  employed  above.  More  specifically  consider 
again  process  P.  A  description  of  its  behavior  can  be  sufficiently  captured  by  exactly  two  actions:  an  input  of  an  integer 
followed  by  the  ouput  of  this  integer.  Based  on  this  idea  the  notion  of  symbolic  transition  graphs  [9]  and  transition  graphs  with 
assignment  [16]  were  proposed  and  shown  to  capture  a  considerable  class  of  processes. 

In  this  section  we  present  symbolic  graphs  with  assignment  for  ACSR-VP  processes.  As  it  is  not  the  intention  of  the  paper 
to  present  in  detail  the  process-calculus  theory  of  this  work,  we  only  give  an  overview  of  the  model  and  we  refer  to  [13]  for  a 
complete  discussion. 

2.2  Symbolic  Graph  with  Assignment 

The  notion  of  a  substitution,  which  we  also  call  assignment,  is  defined  as  follows.  A  substitution  is  any  function  9 :  X 
Expr,  such  that  9{x)  ^  x  for  a  finite  number  of  x  G  X .  Given  a  substitution  9,  the  support  (or  domain)  of  6  is  the  set  of 
variables  D{9)  =  {x  1 9{x)  ^  x}.  A  substitution  whose  support  is  empty  is  called  the  identity  substitution,  and  is  denoted  by 
Id.  When  |Z?(0)|  —  1.  we  use  [0(x)/x]  for  the  substitution  6.  Given  two  substitutions  9  and  cr,  the  composition  of  9  and  a  is 
the  substitution  denoted  by  9\  a  such  that  for  every  variable  x,  9\ cr(x)  =  cr(£?(x)).  We  often  write  9o  for  9;  cr. 

An  SGA  is  a  rooted  directed  graph  where  each  node  n  has  an  associated  finite  set  of  free  variables  fv(n)  and  each  edge  is 
labeled  by  a  guarded  action  with  assignment  [16, 23].  Note  that  a  node  in  SGA  is  a  ACSR-VP  term. 
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Definition  2.1  (SGA)  A  Symbolic  Graph  with  Assignment  (SGA)  for  ACSR-VP  is  a  rooted  directed  graph  where  each  node 
has  an  associated  ACSR-VP  term  and  each  edge  is  labeled  by  boolean,  action,  assignment,  ( b ,  a,  9). 


Figure  2:  Rules  for  constructing  Symbolic  Graphs  with  Assignment 

Given  an  ACSR-VP  term,  a  SGA  can  be  generated  using  the  rules  in  Figure  2.  Transition  P  P'  denotes  that  given 
the  truth  of  boolean  expression  b,  P  can  evolve  to  P'  by  performing  actions  a  and  putting  into  effect  the  assignment  9.  The 
interpretation  of  these  rules  is  straightforward  and  we  explain  them  by  an  example:  Consider  the  following  process.  Process 
P(0)  can  output  the  sequence  of  events  o!0  infinitely  many  times. 

P{x)  Hf  (ala;,  l).Q(x) 

Q(V)  =  (y<0)->(a!y,l).Q(y  +  l) 

+  (y  >  0)  ->  (a!y  —  1,  l).Q(y  —  1) 

Following  SGA  represents  the  process  P(0). 

y<=0 
(aty.l) 
y:=y+l 

y>0 
y:=y-l 
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One  possible  interpretation  of  our  SGA  can  be  given  along  the  lines  of  programming  languages:  Process  P  can  be  thought 
of  as  a  procedure,  so  that  P( 0)  represents  a  call  to  P  with  actual  parameter  0  which  is  accepted  by  P  with  formal  parameter  x 
declared  in  P’s  body.  According  to  its  definition,  P  outputs  o!0  and  calls  process  Q  with  actual  parameter  0.  Process  Q  then 
checks  the  validity  of  condition  y  <  0  or  y  >  0.  If  y  <  0  is  satisfied,  process  Q  outputs  o!0  and  calls  Q  with  actual  parameter 
y  +  1,  where  the  value  of  y  is  0  in  this  case.  Similar  reasoning  can  be  applied  for  the  condition  y  >  0.  We  believe  that  this 
interpretation,  being  similar  to  that  of  function  calls  and  parameter  passing  in  programming  languages,  is  an  intuitive  way  of 
interpreting  the  ACSR-VP  terms. 


2.3  The  prioritized  Symbolic  Transition  System 

We  have  illustrated  how  ACSR-VP  processes  can  be  given  finite  representations  as  SGA’s  via  the  symbolic  transition  relation 

However,  this  relation  makes  no  arbitration  between  actions  with  respect  to  their  priorities.  To  achieve  this,  we  refine 
the  relation  to  obtain  the  prioritized  symbolic  transition  system  This  is  based  on  the  notion  of  preemption  which 
incorporates  our  treatment  of  priority,  and  in  particular  on  relation  >-,  the  preemptive  relation,  a  transitive,  irreflexive  relation 
on  actions  [2].  Then  for  two  actions  a  and  (3,a>-p  denotes  that  a  preempts  /?,  which  implies  that  in  any  real-time  system,  if 
there  is  a  choice  between  the  two  actions,  a  will  always  be  executed.  For  example  (c?x,  2)  >-  (c?x,  1)  and  {(r,  2)}  >-  {(r,  0)}. 

Extending  the  notion  of  preemption  in  the  value-passing  setting  involves  dealing  with  the  presence  of  free  variables  in 
process  descriptions.  For  example,  given  actions  a  =  (c?x,yi)  and  f3  =  (c?x,  3/2),  whether  a  >-  /?  or  /?  >-  a.  depends  on 
the  values  to  which  variables  j/i  and  y2  are  instantiated.  This  idea  can  easily  be  incorporated  to  yield  the  prioritized  transition 
relation  .  For  the  precise  definition  we  refer  the  reader  to  [13].  We  illustrate  this  with  an  example.  Consider  process  P: 


P(x)  ®  (o?y,l ).P'(*,y) 

P'(x,y)  =  (y  <  1)  — >  (o!(x  +  y),y).NIL 

+  (y  <  2)  -+  (a!(x  +  y),2).NIL 


Figure  3  shows  the  unprioritized  SGA  for  P  and  its  prioritized  version,  Q.  Note  that  transition  P' 


y<l,(o!(g-^v),y),|d 


NIL  is 


preempted  by  P'  NIL  since  whenever  the  former  is  enabled,  the  latter  is  also  enabled  with  a  higher  priority 

(that  is,  whenever  y  <  1,  we  have  y  <  2  and  y  <  2). 


,rue’  Hi 


y<~I .  (a!(x+y).y).  Id* 


y<=2,  (a  !  (x+y) ,  2) .  Id 


(a?y .  1) ,  Id  — v  y<-2 .  (a  !  (x+y) .  2) .  Id 

— - • 


Figure  3:  SGA  of  P  and  Q 


2.4  Weak  Bisimulation 

Various  methods  have  been  proposed  for  the  verification  of  concurrent  processes.  Central  among  them  is  observational  equiva¬ 
lence  that  allows  to  compare  an  implementation  with  a  specification  of  a  given  system.  Observational  equivalence  is  based  on 
the  idea  that  two  equivalent  systems  exhibit  the  same  behavior  at  their  interfaces  with  the  environment.  This  requirement  was 
captured  formally  through  the  notion  of  bisimulation  [19],  a  binary  relation  on  the  states  of  systems.  Two  states  are  bisimilar, 
if  for  each  single  computational  step  of  the  one,  then  there  exists  an  appropriate  matching  (multiple)  step  of  the  other,  leading 
to  bisimilar  states. 

In  this  setting,  bisimulation  for  symbolic  transition  graphs  is  defined  in  terms  of  relations  parameterized  on  boolean  ex¬ 
pressions,  of  the  form  where  p  q  if  and  only  if,  for  each  interpretation  satisfying  boolean  b ,  p  and  q  are  bisimilar 
in  the  traditional  notion.  In  [13]  the  authors  have  proposed  weak  version  of  bisimulations  for  SGA’s,  that  is  observational 
equivalences  that  abstract  away  from  internal  system  behavior  (both  for  late  and  early  semantics).  Furthermore,  algorithms 
were  presented  for  computing  these  equivalences.  Given  two  closed  processes  whose  symbolic  transition  graphs  are  finite,  the 
algorithm  constructs  a  predicate  equation  system  that  corresponds  to  the  most  general  condition  for  the  two  processes  to  be 
weakly  bisimilar. 

Recall  process  P(x)  from  Section  2.3.  Furthermore,  consider  the  following  process  with  bound  variable  x': 
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R(x')  =  (a?y',  l).R'(x',y') 

R'(x', y’)  =f  (y>  <  2)  ->  (a!(x'  +  y’  +  l),2).NIL 

,  ,Thf  P"°"tized.SG^  for  R  is  similar  to  Q  with  the  exception  that  after  receiving  a  value  via  channel  a,  R  outputs  value 
system  +  1  A?P  ymg  ^  Symbohc  bisimulatl°n  algorithm  for  processes  P  and  R,  we  obtain  the  following  predicate  equation 

Xqo(x,x’)  =  VzXu(z,x,x’) 

Xn(z,x,x')  =  z  <2 z  <2  Ax  +  z  =  x' +  z +  1 
A  z<2-+z<2Ax'  +  z  +  l  =  x  +  z 

This  equation  system  can  easily  be  reduced  to  the  equation  X0o(x,  x')=x  =  x'  + 1,  which  allows  us  to  conclude  that  P(x) 
and  R{x  )  are  bisimilar  if  and  only  if  x  =  x'  +  l  holds.  In  general,  since  we  are  dealing  with  a  domain  of  linear  expressions 
predicate  equations  obtained  from  the  bisimulation  algorithm  can  be  solved  using  integer  programming  techniques  [24]. 


3  Real-time  Scheduling  Problems 

In  this  section,  we  show  how  a  problem  of  real-time  system  scheduling  can  be  specified  and  analyzed  using  ACSR-VP.  Accord¬ 
ing  to  [29],  real-time  scheduling  problems  can  be  categorized  into  the  following  three  groups:  priority  assignment,  execution 
synchronization,  and  schedulability  analysis  problems.  The  priority  assignment  problem  requires  assigning  priorities  to  jobs 
so  that  the  system  schedulability  is  maximized.  The  execution  synchronization  problem  is  the  problem  of  deciding  when  and 
how  to  release  jobs  so  that  the  precedence  constraints  are  satisfied  and  the  system  schedulability,  as  well  as  other  performance 
concerns,  are  optimized.  Schedulability  analysis  problem  is  the  problem  of  verifying  that  a  system  is  schedulable,  given  a 
certain  priority  assignment  method  and  execution  synchronization  method. 

Classic  examples  of  solutions  to  these  problems  include  the  rate-monotonic  priority  assignment  problem  on  a  single  proces¬ 
sor  [17].  It  uses  static  priority  assignment,  where  the  priority  of  each  job  is  assigned  in  the  inverse  order  of  period;  a  job  with 
the  shortest  period  has  the  highest  priority.  Deadline-monotonic  priority  assignment  was  proposed  by  [15],  where  the  system 
has  jobs  with  arbitrary  relative  deadlines.  J 

The  same  groups  of  problems  can  be  considered  in  the  presence  of  end-to-end  scheduling  constraints.  Gerber  et  al.  [7] 
proposed  the  method  to  guarantee  a  system’s  end-to-end  requirements  of  real-time  systems.  In  [30],  Tindell  et  al.  attempted  to 
compute  upper  bounds  on  the  end-to-end  response  time.  They  also  proposed  priority  assignment  in  distributed  system  where 
jobs  have  end-to-end  deadlines.  In  [1],  Bettati  studied  the  problem  of  scheduling  a  set  of  jobs  with  arbitrary  release  times  and 
end-to-end  deadlines. 

Our  Approach.  We  propose  to  address  real-time  scheduling  problems  by  means  of  analysis  based  on  ACSR-VP.  In  this 
approach,  a  specific  instance  of  a  problem  is  specified  as  an  ACSR-VP  expression  and  symbolically  analyzed.  Figure  4  shows 
the  overall  structure  of  our  approach.  Rectangles  with  thick  lines  represent  tools,  and  ovals  in  them  represents  the  functional 
blocks  inside  tools.,  Rectangles  with  curved  comer  are  text  artifacts  used  as  input/output  for  tools.  We  specify  scheduling 
problems  in  the  real-time  system  with  unknown  timing  or  priority  parameters  in  the  restricted  form  of  ACSR-VP.  The  restricted 
form  of  ACSR-VP  is  defined  to  ensure  that  resulting  SG  (Symbolic  Graph  without  assignment)  derived  from  SGA  is  finite. 

With  a  given  set  of  ACSR-VP  processes  in  the  restricted  form,  the  SGA  is  generated  to  capture  the  semantics  of  model. 
There  are  two  paths  that  lead  us  to  a  solution.  With  the  first  path,  we  can  generate  the  finite  SG  from  the  SGA  and  check 
bisimilarity  with  an  infinite  idle  process.  The  result  is  a  boolean  expression  with  unknown  parameters.  This  kind  of  boolean 
expression  can  be  solved  using  integer  programming,  e.g.,  Omega  Test  [21],  to  find  all  solutions  of  the  parameters.  With  the 
second  path,  the  generated  SGA  is  checked  symbolically  whether  it  is  bisimilar  to  an  idling  process.  Here,  the  result  is  a  set 
of  predicate  equations  with  unknown  parameters.  This  resulting  set  of  equations  can  then  be  translated  into  a  constraint  logic 
program  or  into  a  boolean  formula. 

For  a  real-time  scheduling  problem,  if  a  solution  to  a  boolean  expression  or  to  the  set  of  predicate  equations  exists,  then 
it  identifies  under  what  values  of  unknown  parameters  the  system  becomes  schedulable.  Thus,  the  schedulability  analysis  is 
performed  symbolically.  For  instance,  in  the  rate-monotonic  scheduling  shown  below,  we  want  to  find  the  periods  of  jobs  to 
guarantee  that  a  system  can  be  scheduled.  We  call  this  problem  the  period  assignment  problem.  In  this  problem,  we  let  periods 
be  free  variables  and  describe  a  system  as  ACSR-VP  process  terms.  These  free  variables  appear  in  the  resulting  boolean 
expression  or  predicate  equations  that  are  generated  from  the  bisimulation  algorithm.  Solutions  for  free  variables  represent  the 
valid  ranges  of  periods  of  the  jobs,  which  make  the  system  schedulable. 
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Figure  4:  Our  Approach  to  Real-time  Scheduling  Problem 

Our  method  is  expressive  to  model  complex  real-time  systems  in  general.  Furthermore,  it  is  effective  in  the =  sense >  that  the 
resultin'*  boolean  formulas  and  predicate  equations  can  be  solved  efficiently.  For  instance,  there  has  been  active  research  [6] 
to  solve* boolean  formulas  efficiently,  and  there  are  existing  tools  such  as  omega  test  [21)  which  are  ver> f  f“  J^nsttaints 
predicate  equations,  there  are  constraint  programming  techniques  that  are  known  for  solving  linear  (inequation  constrain^ 
efficiently  \\0  24]  Furthermore,  the  size  of  the  SGAs  constructed  from  ACSR-VP  terms  is  significantly  smaller  than  th 
of  Labeled  Transition  Systems(LTS)  constructed  from  ACSR.  Consequently,  this  greatly 

and  thus,  we  can  now  model  larger  systems  and  solve  problems  which  are  not  possible  using  ACSR  (and  its  toolset 

^We*now  Ubsteate^ouTapprorwh  by  showing  how  to  solve  a  rate-monotonic  scheduling  problem,  known  as  die  period 
JZZPSZZ  Z  method  of  solving  L  problem  is  optima!  in  the  sense  that  if  the  method  can  not  Sod  a  penod 
assignment,  then  the  system  cannot  be  scheduled  for  any  assignment  of  periods. 

J<*i(Pi,r>i,«t)  ='  (s,<B,)A((,<A)  ->  «cp»  MAX-p,)}tJob1(p„s,  +  l,ti  +  l) 

+  v  •  J Ovi\Pi)  ti  “T*  1/  * 

+  ($i  =  Ei)  A  (U  <  Di)  -+  WaitipuU) 

Waitiiputi)  d=  (ti<Pi.ma*)A(fi<Pi)  -* 

+  Ih  <  Pi, max)  A  (*i  =  Pi)  -4-  (r,l).Jofii(Pi,0,0) 
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penod.  That  is,  the  job  with  shortest  period  has  the  highest  DnoritWf  tr, P  Snjf-  ^  P"  Wbere  is  the  largest  possible 

in  that  time  unit.  Alternatively,  if  the  job  has  completed  (s  •  =  E-T'ift^  toto  afcgher-priority  process,  it  idles 

end  of  the  current  period  and  restarts  itself.  P{  Jx  represents  th 1  he  Process.  which  idles  until  the 

monotonic  settii^,  priorities  are  unknown  sincethe  pe^^o^^h  job^noHmown111  ^  U*  ^  ^  ^  this  rate 

For  a  job  Jobi  where  penod  is  known  to  be  Pit  it  can  be  described  as  follows: 

Jobi(si,ti)  =  (s;  <  Ei)  A  (u  <  Di)  ->  {{cpu,  MAX  -  P;)}  :  Jobi(Si  + l,fi  +  i) 

,  +  0  :  Jobifsi.ti  +  1) 

+  (si  =  Ei)  A  (ti  <  Di)  -4  Waitfc) 


Waiti(ti)  =  (ti  <  P^ 


-*■  0  :  W ait i(ti  4- 1) 
(r,l).7o6i(0,0) 


+  (ti  =  Pi) 

'  ’  '  w  \  ~  •  - 1 

Assuming  that,  initially,  all  jobs  start  at  time  0,  we  can  capture  the  behavior  of  the  whole  system  as  follows. 

RM(f)  M  1*6,11... ||  MJ(W) 


btimulato  ’refation  with in^im tile  °Tf0)  *****  "* 

of  predicate  equations  o,  a  boolean  expression  if  we  * *SG T  JT  ‘n  I13)'  The  res“h  is  a  « 

automatically  by  the  existing  integer  programming  tool.  '  the  SG.  A  boolean  expression  can  be  solved 

4  PARAGON  Toolset 

Their  usefulness  will  al20nthms  deSCr.ibed  in  the  PrecedinS  ^Uons 

where  symbolic  analysis  can  be  supplemented  by  other  analvsis  terh"3"  ext®nsi''e  specificatl0n  and  verification  framework, 
PA^p?™271-’ a  t00lSCt  baSCd  °"  ACSR  and  other  related  formalisms!11165  ^  rameWOrk  can  be  provided  by  extending 

ports  both  graphical  andTexteaUnpSrS  systems.  PARAGON  sup- 

sentation  of  hierarchy  modules  in  the  system  and  of  inters  >■  u  ^  e  usabihty  of  a  formed  model,  giving  a  visual  repre- 
are  expressed  using  the  GCSR  language,  based  on  a  realWpr^  *n  PARAG0N 

which  consist  of  nodes,  connected  by  edges.  The  execution  of  the  svstem  nmrtJtef  Spec,lficatl0njls  a  collection  processes, 

treatment  of  data  value,  is  currently  misting  in  PARAGON.  Every  parametod ^  ”eV"’ 
non-parametenzed  one,  and  handling  of  parameterization  during  malysis  is  T“  '’“  I1  °  * 

This  approach  is  vety  inefBcient,  ns  it  creates  a  separate  procesf  for  ew  ns^Uafen  rfLT?  •  m2'"E  “ansIa“on' 
tenzed  process,  many  of  which  are  not  necessary  for  the  subsequent  analvsis  Tbemfom  b  VanableS  ”  the  P"anK; 

representation  that  handles  index  variables  symbolically,  such  «  SGA  described  in  Ms ^  ““  * 
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5  Conclusions 


We  have  described  a  formal  framework  for  the  specification  and  analysis  of  real-time  scheduling  problems.  Our  framework  is 
based  on  ACSR-VP  and  symbolic  bisimulation.  The  major  advantage  of  our  approach  is  that  the  same  framework  can  be  used 
for  scheduling  problems  with  different  assumptions  and  parameters.  In  other  scheduling-theory  based  approaches,  new  analysis 
algorithms  need  to  be  devised  for  problems  with  different  assumptions  since  applicability  of  a  particular  algorithm  is  limited  to 
specific  system  characteristics. 

We  believe  that  ACSR-VP  is  expressive  enough  to  model  any  real-time  system.  In  particular,  our  method  is  appropriate  to 
model  many  complex  real-time  systems  and  can  be  used  to  solve  the  priority  assignment  problem ,  execution  synchronization 
problem ,  end-to-end  design  problem ,  and  schedulability  analysis  problem .  It  depends  on  light-weight  formal  methods  in  the 
sense  that  resulting  predicate  equation  systems  can  be  solved  with  existing  techniques  such  as  linear  programming  or  constraint 
programming,  which  can  be  solved  using  linear  equation  constraints  efficiently  in  practice  [24]. 

The  novel  aspect  of  our  approach  is  that  parametrized  design  of  a  real-time  system  can  be  described  formally  and  analyzed 
automatically,  all  within  a  process-algebraic  framework.  It  has  often  been  noted  that  scheduling  work  is  not  adequately  inte¬ 
grated  with  other  aspects  of  real-time  system  development  [3].  Our  work  is  a  step  toward  such  an  integration,  which  helps  to 
meet  our  goal  of  making  the  timed  process  algebra  ACSR  a  useful  formalism  for  supporting  the  development  of  reliable  real¬ 
time  systems.  Our  approach  allows  the  same  specification  to  be  subjected  to  the  analysis  of  both  schedulability  and  functional 
correctness. 

There  are  several  issues  that  we  need  to  address  to  make  our  approach  practical.  We  showed  that  resulted  predicate  equation 
systems  can  be  solved  with  constraint  logic  programming  or  linear  programming,  but  they  can  be  rather  complicated.  We  plan 
to  investigate  when  resulting  equation  systems  become  easy  or  difficult  to  solve.  In  the  worst  case,  we  may  have  to  use  a 
more  powerful  technique  such  as  theorem  prover;  however,  it  is  not  clear  whether  any  reasonable  real-time  system  scheduling 
problem  can  result  in  such  a  complex  equation  system.  We  are  currently  augmenting  PARAGON,  the  toolset  for  ACSR,  to 
support  the  full  syntax  of  ACSR-VP  directly  and  implementing  a  symbolic  bisimulation  algorithm.  This  toolset  will  allow  us 
to  experimentally  evaluate  the  effectiveness  of  our  approach  with  a  number  of  large  scale  real-time  systems. 
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One  of  the  problems  in  developing  ANDES,  an  expert  system  for  diagnosis  of  the  US  Air  Fnrrp 

ground  station  antenna  system  at  the  Antenna  Repair  Facility  of  McClellan  Air  Force  *  h  *  ^  sa  ellite 
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1.  BACKGROUND 

mnint-o'  ^  l"0’3  the  Antenna  Repair  Facility  (ARF)  at  McClellan  Air  Force  Base  received  the  task  of 

flat  Dhi«dSaa^vS  Statl0n  antenna  SyStem'  Each  antenna  in  the  antenna  system  is  a  three-by-four-foot 

flat  phased-array  with  128  identical  elements  (or  subantennas)  on  two  radio  frequency  (RF)  circuit  boards  with  two 

no.se  amplifiers  (LNA)  and  a  four-voltage  type  supply.  Four  digital  circuit  elds  S 

inducmS  7  efSment  7  ab°Ut  \wo  d°“n  Physical  components  (including  a  phase  shift  circuit  consisting  of  RF  diodes 
inductors,  capacitors,  and  resistors),  thus  resulting  in  over  2000  components  in  each  antenna  Three  diode  pairs  Drovide 

5  degrees  for  each  elemem' Ths  aaJor  compo”“B  - 

fll7ahnTgh  StrideS  h3Ve  been,made  on  automating  measurement  collection  and  testing  methods  since  ARF  has  been 

l  nt  nro:rrnCe  rl  2,3-’  diagnosis  is  sti11  comPlex  and  analysis-intensive  and  remains  predominantly  a 
"  J“S  on  .the  ®1®ment  and  maJ°r  component  level,  the  input  data  measurements  number  in  the  thousands  The 

fiXE  ,  C°nS1St  °f  d°lenS  °f  teStS’  ThC  required  Ski11  Ievel  for  *e  "¥<*  technician/engineer  ishi^lemanifing 
repair  this  ^  of'antennrt T108;^’  ?peration  and  data  Pressing.  Training  a  new  technician  or  engineer  to 

Sev“a' ye“s  of  *■*«  J  bsfore 

their  in  hous^ex^SSnl^'  1°'°?  scheduled  t0  close  in  a  few  years,  ARF  faces  a  new  challenge  of  maintaining 

maintenance W, TJL H  P.r°du,Ctl0n 'evf  23  manP0Wter  ^creases,  and  transferring  their  many  years  of  skill  in  antenna 
(ANtenna  D’a«»n  C  0S‘ng  base.  t0  tbe  ac9uinng  base.  To  meet  the  challenge,  an  expert  system  called  ANDES 

(ANtenna  Diagnostic  Expert  System)  is  being  developed  to  help  human  engineers  improve  the  antenna  diagnostic  process. 

modular  t^^l£Vel°Pe|! !"  CUPS’  *  rule:based  exPert  system  she11  environment  [4,9].  It  is  designed  with  a  layered 
Se  21  S  IT  C°n,S1StS  a  S\°UP  °f  m0dU,CS  imPIementin8  a  Particular  system  function  (refer  to 

o  her  hand  daiaTu^H  l  l  7“ layer  °nly  be  inVoked  by  in  a  WSher  Iayer.  b«  not  vice  versa.  On  the 

25  b  d’ d  ?  f  d  m  a  hlgher  layer  can  be  exP°rted  to  a  lower  layer  module,  but  not  vice  versa.  Such  a  design  lends 

process  venf,caboa>  flexibdlty  and  expandability.  Because  of  the  nature  of  the  antenna  diagnostic 

'h  ?  factors  afe  incorporated  into  its  knowledge  base.  ANDES  has  a  command  language  interface  with  the 

duril  ?he  timefJd  St  '  “7™  ^ostic :Problen“  (ten  different  categories).  The  ANDES1  experience  indicates  that 

nZ  rflT  fd  US' Streamlinmg  and  r«stnicturing.  expert  systems  offer  a  viable  and  sometimes  pivotal  means 

and  llThir  ?efSerVe  a  fXpTu  T  a  d0sing  base’  (2)  t0  Provide  a  Gaining  tool  for  the  acquiring  base, 

ana  (3)  to  help  maintain  productivity  during  the  base  shutting  down  period. 
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Figure  1.  128-element  phased-array  antenna. 

an)Mna  °"e°fthe  Pr°Wems  during  the  development  of  ANDES  is  how  to  automatically  generate  useful  facts  from  raw 
antenna  test  data  so  as  to  facilitate  the  diagnostic  process.  Because  of  the  lack  of  knowledge  acquisition  tools  to  aid  the  task, 

Z  lefir,  a,w  ‘C  m°,del  f0r  the  raw  test  data  and  verify that  the  model «  valid.  Algorithms  are  then  developed  based  on 
the  model  that  are  used  to  automatically  generate  diagnostic  facts  from  the  test  data  for  antenna  diagnosis  process.  Our 

experience  indicates  that  statistic  models  are  useful  in  helping  automate  the  knowledge  acquisition  process  and  that  domain 
specific  information  is  needed  in  defining  the  automation  algorithms. 

The  focus  of  the  paper  is  thus  on  the  facts  generation  layer  in  ANDES'  structure  (see  Figure  2).  The  remainder  of 
the  paper  is  organized  as  follows.  Section  2  deals  with  the  raw  antenna  test  data  and  how  human  experts  perform  the  data  to 
tacts  generation  process.  Section  3  discusses  the  statistical  model  for  the  test  data.  Its  validity  is  verified  in  Section  4. 

in  Section  5  that uti«zed  by  ANDES  in  generating  diagnostic  knowledge  from 
raw  antenna  test  data.  Finally,  Section  7  concludes  the  paper  with  remarks  on  future  work. 

2.  ANTENNA  SCAN  DATA 

In  identifying  symptoms  during  an  antenna  diagnostic  process,  there  needs  to  be  facts  that  describe  an  antenna’s 
properties  m  terms  of  some  qualitative  terms  such  as  low,  high,  good,  bad,  and  so  forth.  Before  we  are  able  to  discuss  how 


these  facts  are  directly  generated  from  the  raw  test  data  (RF  diagnostics  and  back  transform  scan  data),  we  need  to  take  a 
look  at  its  format  as  follows. 


output 


Figure  2.  Structure  of  ANDES. 


(1.1)  (1,2)  (1,3)  (1,3)  (1,4)...(1,  nx-4)  (1,  nx-3)  (1,  nx-2)  (1,  nx-l)  (1,  nj 

(2.1)  (2,2)  (2,3)  (2,3)  (2,4)...(2,  nx-4)  (2,  nx-3)  (2,  nx-2)  (2,  nx-l)  (2.  nx) 

(3.1)  (3,2)  (3,3)  (3,3)  (3,4)...(3,  nx-4)  (3,  nx-3)  (3,  nx-2)  (3,  nx-l)  (3,  nx)  ' 

(4.1)  (4,2)  (4,3)  (4,3)  (4,4)...(4,  nx-4)  (4,  nx-3)  (4,  nx-2)  (4,  nx-l)  (4,  nx) 

(5.1)  (5,2)  (5,3)  (5,3)  (5,4)...(5,  nx-4)  (5,  nx-3)  (5,  nx-2)  (5,  nx-l)  (5,  nx) 

(6.1)  (6,2)  (6,3)  (6,3)  (6,4)...(6,  nx-4)  (6,  nx-3)  (6,  nx-2)  (6,  nx-l)  (6,  nx) 

(7.1)  (7,2)  (7,3)  (7,3)  (7,4)...(7,  nx-4)  (7,  nx-3)  (7,  nx-2)  (7,  nx-l)  (7,  nx) 

(8.1)  (8,2)  (8,3)  (8,3)  (8,4)...(8,  nx-4)  (8,  nx-3)  (8,  nx-2)  (8,  nx-l)  (8,  nx) 

There  are  8  rows  in  a  data  file  where  each  row  has  nx  scan  readings  across.  Data  items  represent  uniformly  spaced  readings 
taken  on  a  radome  antenna  of  Figure  1,  where  row  1  in  the  file  represents  scan  readings  taken  over  elements  113, ...,  128; 
row  2  represents  scan  readings  taken  over  elements  97, ...,  1 12;  and  so  on,  and  row  8  represents  scan  readings  taken  over 
elements  1, ....  16. 

2.1.  Facts  Generation  by  Human  Experts 

Human  experts'  approach  to  generating  diagnostic  facts  from  the  RF  diagnostic  scan  values  is  summarized  as 
follows:  (1)  They  deal  with  each  row  at  a  time,  creating  a  2-demensional  graph  based  on  scan  data  from  that  row.  (2) 
.Knowing  that  if  the  curve  is  flat,  then  the  elements  within  this  row  are  good,  they  then  look  at  each  graph  and  make 
judgments  on  those  few  readings  in  this  graph  which  are  unacceptably  lower  or  unacceptably  higher  than  the  other  readings 
which  appear  relatively  flat,  or  stable.  These  elements  are  marked  as  suspect.  (3)  The  human  expert  then  looks  at  suspect 
elements  over  all  phase  shift  settings  to  determine  the  specifics  of  the  element  failure. 
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2.2.  Postulation 

3.  THE  STATISTICAL  MODEL 
3.1.  Empirical  Rule:  Standard  Normal  Distribution 

Given  a  fairly  large  sample  from  a  normal  population  where  p  and  c  are  not  known  it  is  not  unreasonable  tn , 
the  sample  mean  X  and  the  sample  standard  deviation  s  as  rough  estimates  for  the  population  mean  u  and  the  pooulation 
standard  deviation  c,  respectively.  The  intervals  have  the  following  data  coverage:  ^  P  pU  atl0n 


Intervals 

Percentage  of  Data  (approximate! 

<X-s,  X+s> 

68 

<X-2s,  X+2s> 

95 

<X-3s,  X+3s> 

99.7 

Recall  from  statistics  that  for  any  normal  variable  x  with  mean  p  and  standard  deviation  o>  0 
P(|i-a<  x  <  p+a)  =  0.6826; 

P(p-2a<  x  <  p+2a)  =  0.9544; 

P(p-3a<  x  <  p+3a)  =  0.9974; 

P(p-4a<  x  <  p+4a)  =  0.99994; 

P(p-5a<  x  <  p+5a)  =  0.9999994;  and  so  forth. 

That  is,  let  X  >  0,  then  since  z  =  (x-p)/o, 

,  ^'a <x< <=>  (p-X-a-p)/a < z <(p-X-a-p)/a  o  -X< z<X- 

J”“  b‘  °b,a'n'd  by  SUmmin8  *h'  >«***“■  the  standard 

.  P(p-X-a<  x<  p+X-a)  =  P(-X<  z<  X) 

Sf;  ,.f°ra  conunuous  random  variable  x,  P(a£  x<  b)  =  P(a<  x<  b),  because  adding  a  and  b  to  the  interval  does  not 

said  that  s  ~  o  "and  J  u  b  T0'  ^  ^  COmparing  the  EmPirical  Rul*  and  the  results  here,  it  can  safely  be 

use  Ae  tand!rH  1 5-  !!  0meS  ^  S°  355111,11112  n  is  large  en0ugh  t0  make  these  estimations,  it  is  permissible  to 

use  the  standard  normal  distribution  curve  to  estimate  probabilities  when  s  and  X  are  known. 

3-2.  Interval  <gmln,gmax> 

confidenceT ZaTuT',1’*  T  TP?'  “*  P°pUlaUon  U  "0rma1'  ”d  *■  <»  some  level  of 

eonBdence  1-a  (,.e  ,f  X  =  1,  the  estimated  leve_l  of  confidence  is  0.6826)  such  that  X  is  expected  to  be  in  the  interval 

,4  ,  7 ,f  ,S  “  x,'  "ot  ■"  <  X-U2.  “  ca"  b'  s!dd  «“  »ith  «  estimated  confidence  level  of 

1  a  x  is  a  candidate  for  not  being  a  value  m  <X-X-s,  X+Ls>.  since  no  x  is  expected  to  be  out  of  <x-X-s  x+X-s>  with 
an  estimated  confidence  level  of  1-a.  * 

average  oTihe  5Ca"  ValueS’ let  <g"*»  &->  =  <*-***  *****  where  Z  is  the 

distributed  and  I ?h  •  52 15  Standarud  devciatI0n  of  ***  scan  vaIues.  provided  that  the  scan  values  are  normally 

Srei  tTb  h  ^nCre  15  3  SUfCient  nUmber  °f  SCan  Values  in  each  row  of  scan-  For  ‘he  latter  requirement,  the 
requirement  that  nx>  30  can  be  made. 

3.3.  Guidelines  to  the  Selection  of  1-a 

Clearly  X  depends  on  the  estimated  level  of  confidence  1-a.  It  is  not  always  desirable  to  have  1-a  extremely  close 

a°badeeCnffSh^nb  *"?“???  “JT*  c°nfidence  interval>  makin2  the  estimation  of  X  less  accurate.  Thus,  there  is 

accuracv^ Ln^! L  “r?  1  °-  ?onf!denice  afd  curacy:  higher  confidence  implies  less  accuracy,  and  more 

y  mphes  less  confidence.  In  statistics,  levels  of  confidence  often  used  are  80%,  90%  95%  98%  99%  which 

approx, mateJy  correspond  to  X  values  of  1.28,  1.64,  1.96,  2.33, 2.58  respectively.  Notice,  here  X  is  just  the  vkue  of  z  such 
that  the  area  under  the  standard  normal  curve  from  0  to  z  is  (l-a)/2  (0<  1-a  <  1,  because  X  approaches  infinity  as  1-a 
approaches  1,  making  X  undefined  as  1-a  reaches  1.  And,  as  1-a  approaches  0,  X  approaches  0,  and  X=  0  when  1-a  =  0; 
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however,  if  X=  0,  the  interval  <  X— X-s,  x+X*s>  becomes  nil,  so  the  requirement  X>  0  is  necessary  to  keep  the  interval 
<  X  -X-s,  X  +X-s>,  which  is  open  at  both  ends,  defined.  Thus,  this  requirement  implies  that  1-co  0). 

3.4.  Determining  X  Given  the  Confidence  Level 

X  is  needed  when  given  the  confidence  level  in  order  to  use  <gmjn.  gm»>.  Recall  from  statistics  that  the  normal 
distribution  is  given  by  the  function 


/(*)=- 


2ffl 


-X 
o  2 


where  x  is  the  random  variable,  |i  is  the  mean  and  a  is  the  standard  deviation.  The  function  simplifies  to  f(x)  —  for 


•JlK 


the  standard  normal  distribution  because  of  its  definition  (jjl  =  0  and  c  =  1).  Thus, 


*  2 

P(0<z<X)  =  [  dx . 

1+ 


This  is  one  of  those  functions  which  cannot  be  integrated.  Therefore,  some  kind  of  series  should  be  used  to  estimate  it.  For 
simplicity,  the  following  Simpson's  Rule  can  be  used. 
b 

|  fix)  dx  =  y  (f(x0)  +  4  /(*,)  +  2  f(x2)  +  4  fix,)  + ...  +  2f(xn_2)  +  4/(x„_,)  +  /(*„)) 


3-A5 


This  means  that  the  maximal  error  of  using  Simpson’s  Rule  with  a  =  0  and  b  =  X  is -  < —  .  Furthermore,  since  X>0,  if 

I80n  V2rr 

n  is  some  even  constant,  necessarily  larger  than  1,  the  maximal  error  in  using  Simpson’s  Rule  in  the  interval  [0,  c]  is 


3-c 


180/i4V2rr 


.  Thus,  if  no  more  error  than  e  is  allowed,  then 


3*c 


\l/4 


180n4V2/r 


<eorn> 


60£-J2k 


Using  the  bisection  method  to  determine  a  particular  X/  where  P(0<  z<  X')  =  (1— a)/2,  it  is  found  that  after  X 
exceeds  4,  with  no  more  error  than  1 0.5—0.49997 1  =  0.00003,  P(0  <  z  <  X)  =  0.5,  where  no  more  error  than  0.00003  implies 
P(0  <  z  <  X)  -  P(0  <  z  <  4)  <  0.00003  for  X  >  4.  Of  course  this  would  bring  in  the  restriction  that  0<  (l-a)/2  £  0.49997,  or 


0<  (1-a)  5  0.99994.  If  c  =  4  and  e  =  0.00001,  then  n  > 


1/4 


^60W2/r  J 


1  =  28.7253;  thus,  we  can  let  n  =  30,  since  n  must  be 


even. 


3.5.  Regression  Function  Z  (x) 

Since  the  elements  are  not  exactly  at  the  points  where  the  scan  values  are  taken,  their  scan  values  would  have  to  be 
estimated  before  the  interval  <gnun»  gm»>  can  be  used  to  determine  the  conditions  for  the  elements.  This  would  require  some 
kind  of  regression  Z  (x).  we  need  to  rely  on  the  scan  values  to  find  Z  (x)  for  an  element  ec  of  column  c  in  matrix  scan. 

In  the  following  matrix  scan,  the  integers  1, 2,  3,  ...nx  mark  the  positions  where  scan  readings  are  taken  in  the  x-. 
axis;  the  integers  1, 2, 3,  ...nu  mark  the  positions  where  the  elements  are  located  in  the  u-xis,  which  is  in  the  same  direction 
as  the  x-axis;  the  integers  1, 2,  3,  ...ny  mark  the  position  where  scan  readings  are  taken  in  the  y-axis;  and  sv  marks  the 
positions  where  scan  readings,  or  values,  are  taken  for  a  pair  (x,  y).  Notice,  the  positions  marked  by  integers  0,  nu+l,  n*+l 
and  ny+l  are  introduced  because  the  scan  readings  and  element  positions  are  uniformly  spaced  on  the  radome  antenna;  that 
is,  although  these  positions  do  not  represent  actual  elements,  they  represent  the  fact  that  an  element  next  to  an  edge  of  the 
antenna  is  within  the  edge  the  same  distance  it  is  within  an  adjacent  element. 
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Th^n  W“  *  *  u  f  U-(n  +1) 

»,  +  r  7 X(U)=  '  wh're  *<«•> is  U>«  relative  position  of  element  e„  in  the  x-axis  (Note:  to  get 

for  element  e,  nVC  Z  W’  Which  13  needed  t0  evaluate  z  W*)),  the  estimated  scan  value 


0 

1 

2 

3 

4 

5 

(ny) 

(ny+l)  -»y 

1 

sv 

sv 

sv 

sv 

sv 

1 

• 

(nu) 

• 

(n*) 

sv 

sv 

sv 

sv 

sv 

(n„+l) 

i 

u 


(nx+l) 

i 


In  determing  8  in  general,  the  number  of  scan  readings  used  between  u,  and  u2  (u,<  u2)  in  column  c  is  given  by 
nc(Ui,  U2)  =  (Tx(u2)l  -1)  -  (  Lx(U|)J  +  1)  +  1  =  r x(u2)l  -  Lx(Uj)J  -  1 . 

So  the  total  number  of  scan  readings  used  from  column  c  is  fcW  f,ne(i-6,  i+S) .  Because  the  scan  data  are  collected 

S^wkhoma  titSSKi from the^ading^oTnemby efeme^.^  =  Clement  “  mu6h  33 

next  TheHEodltdSeefin8;  SUCh  that  Xfe~8>  <  r  <  «**>  can  be  determined 

next  The  goal  is  to  define,  for  a  particular  column,  c,  of  scan  values  with  variables  x  and  z  (x  is  the  dependent  variable  and 

2  is  the  independent  variable),  a  regression  function  z(x)  to  estimate  for  an  element  e  a  scan  value  z  Me  Yk  sinro  th* 
overall  goal  .s  to  find  a  flat  curve.  Ore  best  fit  hue  with  slope  zero  for  the  scan  £ 

regression  fttnchon,  meaning  that  z(x)  is  just  the  average  of  the  scan  readings  in  column  c  where  x(e,-S)  <  r  <  x(e,+S). 
1  hus,  if  6  is  such  that  all  scan  values  in  column  c  are  used,  then  £  (x(ec))  =  z  for  any  ec. 


4.  MODEL  VERIFICATION 


nirVM  „™  .I'"’*,'!!3'  ,I”0deI  “  V,3lid  md  ,he  scan  da,a  d°  f°u°»  the  normal  distribution,  twelve  randomly 

?OTt?ns  fte  folPRF  SSSSe* T  °bt3!n<?  ^  0f  abo“  siM>'  dala  “ts.  Each  set  of  data 

.  RF  diagnostic  scans  of  both  the  magnitude  and  the  phase  types  at  phase  shifts  of  0  45  90  and  180 

d  Slfarlnotf "  ^  T  ^  ^  3  g*“  SWft  °f  315  de8ree  «  not collect^,  so  sL  not  containing  ^*scan  for  315 

?0WeVer,5  SC/n  d3ta  for  315  df*ree  “* deluded  in  a  set,  then  there  must  be  a  file 

Z  d  !  f‘  *  f°r  ^  phaSf  m  °rder  f0r  tlus  set  t0  be  considered  complete.  The  twelve  sets  of  data  selected 

are  from  twelve  different  antennas,  respectively. 


the  twelvtdatf^fS  3  P3irvf,RF  s^an ‘magnitude  and  RF  scan  phase  files  at  some  phase  shift  is  randomly  selected  from 
i d  ,  1  f0r3n  imUal  Probe-  Each  of  1116  two  flles  has  21 1  scan  values  for  each  of  the  eight  rows  making  up 

1,688  scan  values  for  a  file.  Figure  3  and  Figure  4  compare  the  actuals  and  estimates  of  the  scan  data  fothese  two  files. 


Given  n  values,  a  sample  mean  X  and  a  sample  standard  deviation  s  are  calculated.  Let 
count  =  the  number  of  values  in  <  x  -X’s,  x  +X-s> 
actual  —  P(  X  — X"S<  X  <  X  +X-s)  =  count! n, 
estimate  =  P(-X  <  z  <  X), 
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P(— X<  z<  X)  can  be  obtained  by  finding  the  area  under  the  standard  normal  distribution,  the  normal  distribution  curve 
where  p=  0  and  a=  1.  By  comparing  actual  and  estimate ,  an  idea  of  whether  or  not  x  is  normal  will  be  observed.  If  actual  = 
estimate  for  all  Xs,  then  x  is  normal.  If  actual  ~  estimate  for  all  Xs,  then  x  is  approximately  normal. 

Let  X  be  in  the  [0.1,  5.0]  with  AX=  0.1,  for  the  scan  values  in  each  row  of  a  particular  file,  X  versus  actual  and  X 
versus  estimate  are  graphed.  Also  letting  error  =  I  actual  -  estimate  I,  the  average  error  and  the  standard  deviation  of  the 
errors  are  calculated  for  each  graph.  Since  estimate  is  0.9996,  0.99994,  0.999994,  and  0.9999994  for  X  =  3.5,  4.0,  4.5  and 
5.0,  respectively,  and  estimate  «  1  for  X  >  5,  the  range  of  Xs  should  be  sufficient  in  seeing  if  the  data  exhibit  a  normal 
distribution.  The  tool  used  to  generate  these  graphs  and  calculate  these  figures  is  Mathematica  [8]. 


Figure  3.  Actuals  and  estimates  for 
all  scan  values  of  RF  scan  of  type 
magnitude,  phase  shift  of  0  degree 
(avg.  errors  0.01 1 1;  std.  dev.  of  errors=  0.0026) 
(dashed  curve  corresponds  to  actuals,  and  solid 
curve  corresponds  to  estimates) 


prob 

Actuals  £  Estimates 


Figure  4:  Actuals  and  estimates  for  all 
scan  values  of  RF  scan  of  type  phase, 

0  degree  (avg.  error=  0.0073;  std.  dev. 
of  errors=  0.0025)  (dashed  curve  corresponds 
to  actuals,  and  solid  curve  corresponds 
to  estimates) 


prob 

Actuals  €  Estimates 


lambda 


From  Figures  3  and  4  the  randomly  selected  pair  of  files  contains  data  that  appear  to  have  the  normal  distribution, 
so  normality  does  seem  to  exist.  Then,  next  we  look  at  all  the  files  in  the  twelve  sets  of  data  to  see  if  the  data  in  each  file 
exhibit  the  similar  characteristics.  Instead  of  generating  graphs  for  the  data  in  every  file  of  the  twelve  data  sets,  we  choose, 
as  the  average  actual,  the  average  of  the  actuals  for  each  X,  where  X  e  [0.1,  to  5.0]  with  AX=  0.1,  of  all  rows  from  all  files 
for  a  particular  type  (either  magnitude  or  phase),  of  a  particular  degree,  (either  0, 45,  90,  180,  or  315)  in  the  twelve  sets  of 
data.  Thus,  if  the  “average”  row  appears  to  be  approximately  normal,  then  overall  it  can  be  considered  that  the  RF  scan  data 
of  a  particular  type  and  degree  are  approximately  normal.  Taking  this  approach,  graphs  are  generated  for  the  10  possible 
“average”  rows;  that  is,  five  for  rows  of  type  magnitude,  with  phase  shifts  of  0,  45,  90, 180  and  315  degrees,  and  five  for 
rows  of  type  phase  with  phase  shifts  of  0,  45,  90,  180  and  315  degrees.  In  addition,  the  standard  deviation  of  the  average 
actuals  versus  X  is  plotted  for  each  of  the  ten  cdses,  to  show  the  dispersion  of  the  actuals  at  each  X.  The  results  show  that  the 
scan  data  do  observe  the  normal  distribution,  even  though  we  only  include  the  graphs  for  two  cases  due  to  space  limit  (refer 
to  Figures  5-8). 

Looking  at  the  figures  of  the  standard  deviations  and  the  averages  of  the  errors,  it  can  be  said  that  overall  the  scan 
values  are  pretty  close  to  being  normally  distributed.  In  addition,  the  plots  of  the  standard  deviations  of  the  actuals  are  not 
totally  surprising.  For  example,  when  X  is  small,  since  the  actuals  are  small,  due  to  the  small  intervals  used  to  obtain  the 
actuals,  the  standard  deviation  of  the  actuals  is  expected  to  be  small;  when  X  is  large  enough,  the  standard  deviation  of  the 
actuals  is  expected  to  become  smaller  only  for  larger  X,  since  large  intervals  are  expected  to  cause  more  consistent  actuals. 
In  any  rate,  prior  to  becoming  large  enough  as  X  increases,  the  standard  deviation  of  the  actuals  at  X  is  expected  to  increase, 
since  the  intervals  used  to  obtain  the  actuals  are  not  large  enough  to  make  the  actuals  consistent  but  yet  the  intervals  are 
becoming  larger,  giving  the  actuals  more  freedom  to  take  on  different  values. 
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prob 


Figure  5.  Average  actuals  and  estimates 

for  RF  scan  of  type  magnitude,  degree  0 
(avg.  errors  0.0205 ;  std.  dev.  of  errors=  0.0 1 36) 
(dashed  curve  corresponds  to  actuals,  and  solid 
curve  corresponds  to  estimates) 
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Figure  6.  Standard  deviation  of  average 
actuals  for  RF  scan  of  type 
magnitude,  degree  0. 
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Figure  7.  Average  actuals  and  estimates 
for  RF  scan  of  type  phase,  degree  90 
(avg.  error=  0.0043;  std.  dev.  of  errors=  0.0027) 
(dashed  curve  corresponds  to  actuals,  and  solid 
curve  corresponds  to  estimates) 


Figure  8.  Standard  deviation  of  average 

actuals  for  RF  scan  of  type  phase,  degree  90. 
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5.  ALGORITHMS  FOR  AUTOMATIC  FACTS  GENERATION 


/*  5,  nx  and  nu  are  assumed  to  be  global  constants.  */ 

,  .  ,  ,  ,«*(n,+l).. 

function  x( u)  return  ( - —  ); 

(«u+l) 

function  nc(ut,  u2)  return  (Tx^l-LxCu^J-  1); 
function  find_elmt_cond(l-a,  scan) 

/*  scan  is  a  nx-by-ny  matrix  containing  all  the  scans  readings.  *t 
/*  zecavg  is  a  n„-vector  used  to  ultimately  store  the  averages  of  the  z 
where  (x(ec)-8)<  r<  (x(ec)+8).  */ 

/*  sumzc  and  sumzczc  are  maintained  to  calculate  the  average  z  of 
column  c,  zcavg,  and  the  sample  standard  deviation  of  column  c, 
sc,  which  are  needed  to  determine  if  e,.  is  low,  good  or  high.  */ 
for  (c=  1  to  ny)  do 

initialize  all  matrix  elements  of  zecavg  to  be  0; 
initialize  sumz=  0,  sumz2=  0 
for  (r=  1  to  nx)  do 
ifx(0.5)<r<x(1.5) 
zecavg[l]+=  scan[r][c]; 
sumzc+=(scan[r]  [c] ) 
sumzczc+=(scan[r][c])2 
else  if  (x(1.5)<  r<  x(2.5» 
zecavg[2]+=scan[r]  [c] ; 
sumzc+=(scan[r]  [c]) 
sumzczc+=(scan[r]  [c])2 
else  if  (x(2.5)<  r<  x(3.5)) 
zecavg[3]+=scan[r][c]; 
sumzc+=(scan[r][c]) 
sumzczc+=(scan[r][c])2 
else  if  (x(3.5)<  r<  x(4.5)) 
zecavg[4]+=scan[r]  [c] ; 
sumzc+=(scan[r]  [c]) 
sumzczc+=(scan[r]  [c])2 
else  if  (x(4.5)<  r<  x(5.5)) 
zecavg[5]+=scan[r]  [c] ; 
sumzc+=(scan[r][c]) 
sumzczc+=(scan[r]  [c])2 
else  if  (x(5.5)<  r<  x(6.5)) 
zecavg[6]+=scan[r]  [c]; 
sumzc+=(scan[r]  [c]) 
sumzczc+=(scan[r][c])2 
else  if  (x(6.5)<  r<  x(7.5)) 
zecavg[7]+=scan[r][c]; 
sumzc+=(scan[r]  [c]) 
sumzczc+=(scan[r]  [c])2 
else  if  (x(7.5)<  r<  x(8.5)) 
zecavg[8]+=scan[r][c]; 
sumzc+=(scan[r]  [c]) 
sumzczc+=(scan[r]  [c])2 
else  if  (x(8.5)<  r<  x(9.5)) 
zecavg[9]+=scan[r][c]; 
sumzc+=(scan[r][c]> 


sumzczc+=(scan[r]  [c])2 
else  if  (x(9.5)<  r<  x(10.5)) 
zecavg[  1 0]+=scan[r]  [c]; 
sumzc+=(scan[r][c]) 
sumzczc+=(scan[r]  [c])2 
else  if  (x(10.5)<  r<  x(l  1.5)) 
zecavg[  1 1  ]+=scan[r]  [c] ; 
sumzc+=(scan[r]  [c]) 
sumzczc+=(scan[r][c])2 
else  if  (x(  1 1 .5)<  r<  x(12.5)) 
zecavg[  1 2]+=scan[r]  [c]; 
sumzc+=(scan[r][c]) 
sumzczc+=(scan[r][c])2 
else  if  (x(12.5)<  r<  x(13.5)) 
zecavg[  1 3]+=scan[r][c]; 
sumzc+=(scan[r][c]) 
sumzczc+=(scan[r]  [c])2 
else  if  (x(13.5)<  r<  x(14.5)) 
zecavg[14]+=scan[r][c]; 
sumzc+=(scan[r][c]) 
sumzczc+=(scan[r]  [c])2 
else  if  (x(14.5)<  r<  x(15.5)) 
zecavg[  1 5]+=scan[r][c]; 
sumzc+=(scan[r]  [c]) 
sumzczc+=(scan[r]  [c])2 
else  if  (x(15.5)<  r<  x(16.5)) 
zecavg(  1 6]+=scan[r]  [c] ; 
sumzc+=(scan[r]  [c]) 
sumzczc+=(scan[r][c])2 
for  ec=  1  to  nu  do 

zecavg[ec]/=nc(ec-8,  ec+8); 

I*  Note:  scan  values  not  used  to  estimate  any 
antenna  element  are  not  used  in  computing 
sumzc  and  sumzczc.  */ 
zcavg=  sumzc/CrOto,; 


I (nc)tol -sumzczc -sumzc 
SC— »  4 1 


(«c ),o,((nc)ul  -1) 


for  ec=  1  to  nu  do 

if  (zecavg[ec]<  zcavg-sc-find-X(l-a))  then 
assert  antenna  element  [ec+(c-l)n„]  as  low; 
else  if  (zecavg[ej>  zcavg+sc-flnd-X(l-a)) 
then 

assert  antenna  element  [eg+(c-l)-nu]  as  high; 
else 

assert  antenna  element  [ee+(c-l)-nu]  as  good; 
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6.  CONCLUSION 


system  deVC,0f,ment  of  an  «Pe« 

then  verify  the  model  s  validity  in  terms  of  the  test  data  Altrnrifhmc  h  a  ?d  for  the  raw  antenna  scan  data,  and 
generation  of  diagnostic  knowledge  from  raw  antenna  'te«  data  ^NDES  ZcT  77  “*  develoPed  for  automated 
preserving  the  antenna  diagnostic  expertise  helnimr  mainr  •  data  ,  accomplishes  our  goals  of  capturing  and 

offering  a  .raining  tool .for  the  acquiring  base.'lts  performance™  ^mpScVte  of  a  hum“n  expert"8  d0Wn  Peri°d'  ^ 

bare.  Integration  of  ANDES  into^Xa^osf/ew^^^^  refining  and  augmenting  ANDES'  knowledge 

ultimately  demonstrate  ANDES'  payoff.  C  aCquinng  base  1S  another  highly  desirable  goal  that  wfll 
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Abstract 

One  of  the  advantages  of  using  formal  methods  in  design  should  be  that  we  can  be  precise  about  where  out 
•  methods  fail.  However,  it  is  rare  to  find  discussions  in  the  literature  of  problems  in  applying  formal  methods  - 
particularly  in  the  early  stages  of  design.  One  reason  for  this  is  that  failures  are  often  caused  by  the  context  in 
which  a  method  is  applied,  rather  than  by  some  purely  technical  limitation.  Using  examples  from  research  in  which 
I  have  been  involved  I  shall  describe  some  of  the  pitfalls  I  have  encountered  and  which  I  have  observed  frequently 
in  the  research  of  others. 

1  Introduction 

Berry,  in  these  proceedings  [1],  advocates  the  use  of  appropriately  chosen  and  applied  formal  methods  in  the  early 
stages  of  design  lifecycles  -  observing  factors  outside  the  technical  considerations  of  the  methods  themselves  which 
influence  their  success.  This  paper  is  complementary  to  Berry’s  discussion  because  it  looks  at  some  factors  which  can 
lead  to  failure.  It  has  been  unfashionable  for  those  using  logic-based  methods  to  introspect  about  causes  of  failures. 
This  is  a  pity  because  without  the  possibility  of  failure  our  research  isn’t  experimental  and  without  the  ability  to  learn 
from  failure  we  are  unlikely  to  develop  robust  engineering  methods. 

To  avoid  being  accused  of  preying  on  other  unsuspecting  researchers,  I  have  taken  all  the  examples  of  pitfalls  from 
my  own  research  and  where  others  have  been  involved  I  have  generalised  the  examples.  In  none  of  the  projects  I 
describe  were  the  mistakes  fatal  but  this  was  largely  because  they  were  small  scale,  which  made  corrections  simpler 
to  make.  Larger  research  efforts  might  not  have  the  manoeuverability  to  fix  these  problems  at  acceptable  cost.  Once 
explained,  some  of  the  pitfalls  may  seem  obvious  but,  given  how  frequently  signs  of  these  can  be  found  in  the  research 
of  others,  I  suspect  that  they  are  much  easier  to  recognise  with  hindsight  than  to  predict. 

In  what  follows,  I  use  “model”  to  refer  to  the  set  of  logical  expressions  used  to  describe  some  problem.  This  is  used 
instead  of  the  word  “specification”  because  in  early  design  we  often  use  models  of  problems  which  are  not  directly 
specifications  of  systems  (see  [11]  or  the  introduction  of  [12]).  I  have  also  used  the  phrase  “inference  system”  in  a 
broad  sense  to  denote  any  system  which  has  been  built  with  the  intention  of  using  or  synthesising  expressions  in  a 
mathematical  logic. 

2  Choice  of  Inference  System 

Formal  definition  takes  place  within  a  chosen  system  of  inference.  Although  in  theory  there  is  great  deal  of  overlap 
between  inference  systems,  so  that  it  should  be  easy  to  translate  definitions  from  one  to  another,  in  practice  our  choice 
of  system  emphasises  particular  features  of  the  problem.  For  example,  a  modal  temporal  logic  is  a  natural  choice  if  we 
are  tackling  a  problem  where  we  need  to  prove  that  certain  propositions  eventually  hold  of  our  system  model.  However, 
those  inference  rules  which  allow  us  to  deal  readily  with  the  temporal  aspects  of  problems  may  be  a  distraction  in 
problems  where  we  don’t  need  to  prove  temporal  properties.  This  issue  is  well  known  and  is  being  addressed,  in  part, 
by  those  whose  interest  is  in  making  it  easier  to  combine  or  translate  between  inference  systems.  There  remain  some 
subtle  difficulties  which  cannot  be  solved  simply  by  deepening  formal  theory. 

There  are  hundreds  of  specialised  formal  calculi,  for  describing  certain  forms  of  uncertainty;  for  expressing  temporal 
information;  etc.  If  we  are  lucky  enough  to  have  a  problem  which  obviously  suits  a  particular  class  of  calculi  then  we 
may  reduce  our  choice  to  a  few  “front  runners”  but  we  may  have  to  dig  deeply  into  the  theory  of  each  competitor 
before  we  can  decide  on  a  winner.  For  example,  in  [5]  it  is  demonstrated  that  any  problem  representable  in  Dempster- 
Shafer  theory  can  be  represented  in  the  Incidence  Calculus  and  vice  versa.  Unwary  readers  might  be  led  to  believe 
by  this  result  that  the  two  calculi  are  “equivalent”.  This  would  be  a  mistake  because  in  [10]  a  version  of  Incidence 
Calculus  is  described  which  for  some  situations  involving  dependent  evidence  gives  the  intuitively  correct  answer  when 
Dempster-Shafer  theory  does  not.  In  other  words,  the  comparison  between  these  two  inference  systems  depends  on 
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exactly  which  version  of  each  system  wo  „ 

syste,m  ■ but  with°“ dfep 

^rhaps  with  a  lspt0  -befn  •»*<*■  with  a  general-purpose  logic 

?kt  52*  *  w  ,  “re  r0"or^r  ^ ' 55 

special  condition,  (rue,  being usri in  cases  where ctl^ln'Sr'’"  T* P  U  “  alomlc  "oUtoSTS 
represent  concepts  such  as  temporal  change  within  our  model?  ttereSatteUwo  f  h  “  ?  *?d  that  we  neKl  “> 

•  Use  the  same  inference  system  w  ^  .  fc  two  techmcaI  solutions: 

Cakate  [»]•  ”'h'ch  deal  wIth  temPoral  effects.  An  example  is  the  Event 

*  ?^po“C“eSnsTr  “S  ^  ***  “  ■“  —  change.  An  example  is  the 

the  extension  to  the  lo^c  w“th  othem  aortdng  m  °°i  PUreIj;' tedmical:  »  fa  necessary  to  negotiate 

perform  in  the  new  style.  The  reason  why  thfs  1  bec„°  '  >  "t?”  them in  the  *•*»  »Ud>  they  S» 

are  modelling  often  are  loosely  bounded  ind  it  is  easy  to  find’ “®us  ,pr°i>le!n  ln  early  design  is  that  the  problems  we 
temporal  extension  when  there  are  also  interest  in  <r  ;J  *??  complex  logical  puzzles  within  them.  Why  stOD  at  a 
can  find  in  the  problem  if  we  stare  hard  enough?  Such  funCti°n  appUcation-  et'  which  we 

down  a  _  slippery  slope”  of  increasing  language  complexity  Scurtl T  h  ogicians  m  a  project  so  it  is  easy  to  slide 
in  addition  to  the  normal  technical  overheads5  P  7’  S  cumulatlve  cost  in  negotiation  and  education 


3  Boundaries  of  Formality 


ne1Ydta^bJ*ldXaniP“^tin®^”na^pr^^Pca ta  a  domaln  of  application. 

necessary  to  commit  to  a  human  interpretation  of  at  leastsome  of  the  f^6 1Jlterfa^e to  the  formal  system,  it  will  be 
system  A  system  for  deciding  on  the  mappings  between  human  and  form^f  ^  manipuIated  b7  the  inference 
an  onto  ogy.  To  work  perfectly,  everyone  who  needs  to  use  aTontoW  m,  ^  S°me  d°main  is  often  called 
uman  to  formal  representation.  There  are  two  surprises  here-  the  fiL  h  b  f°  j W  ^  ?me  conventions  in  relating 
ontologies  can  be;  the  second  is  that  usable  systems  can  bP  nmH  /  1  ^OW  deep  dlfferences  in  interpretation  of 
In  the  knowledge  based  systems  Produced  even  when  such  differences  occur. 

a  survey).  The  most  common  strategy  is  to  L  on  a  bouncSTma^  f^T  &  maj°r  reSearch  theme  (see  [14]  for 
language  which  those  working  in  the  domain  use  to  describe  problems'1  Thtft^T  ^  deViS6  a  restricted  formal 
sharing  information.  In  our  ecological  work  [13]  we  attempted  to  do  thl  r ^  S^ared  )anSuage  1S  used  as  the  basis  for 
he  idea  being  to  use  the  domain  ontology  t  T  0/ecol°^  niodeUing  problems  - 

the  formal  problem  description  to  control  the  generation  of  aim  •  ecoIoSlsts  describe  problems  and  then  to  use 
o  worry  about  what  words  like  “biomass”  ^  This  meaat  that  we  had 

is  question  is  different.  The  most  crude  definition  is  “mass  of  bioWirfl  °  ^ W^°  one  spea^s  to,  the  answer  to 
be  mass  of  biological  material  once  all  water  has  been  removed”  Fnf  ^  ni^efnaI  *  ^  more  Precise  definition  might 
mass  of  biological  material  which  has  been  subjected  to  the  follow,Wt  T  (  sub-domains  the  definition  might  be 
here  is  no  broadly  applicable  definition  of  TV  *  ^her  words, 

to  thismigTt ^t^hya^y  fron^doma^q)edficront^ogiWere “Clfartedeven for domSxp^oVe^tfon 
b0' T“S  r°U,e  alSOfei,S’  °”  “d0mato-M'P“^"  tamffnology 

formal  Celadon  of  bic* 
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place  on.  the  uai  mailing  list  in  the  early  summer  of  1998.  At  issue  was  the  common  practice  of  referring  to  the  X 
in  the  expression  P{X  =  x),  where  P  is  the  probability  that  X  has  value  x,  as  a  “random  variable”.  This  sort  of 
notation  is  often  used  formally  to  represent  statements  like  “The  probability  that  the  colour  of  my  car  is  black”,  which 
might  be  P  {car  .colour  =  black).  The  difficulty  is  that  from  the  point  of  view  of  classical  first-order  logic  it  is  hard  to 
think  of  car. col  our  as  a  logical  variable  -  one  feels  obliged  to  think  of  it  as  a  function  from  cars  to  colours.  On  the 
other  hand,  it  is  often  natural  to  describe  it  as  a  “variable”  because  it  is  one  of  the  points  in  a  problem  description 
for  which  we  are  interested  in  variation.  This  is  a  different  notion  of  variable  than  the  classical  logical  one  but  is  no 
less  valid,  and  has  similarities  to  the  use  of  expressions  such  as  “state  variable”  in  process  modelling.  Although  the 
use  made  of  variables  (of  whatever  kind)  is  precise  and  internally  consistent  within  inference  systems,  the  way  we  use 
natural  language  to  refer  to  them  differs  across  inference  systems. 

It  seems  that,  no  matter  what  we  do,  we  cannot  achieve  a  perfect  ontology.  Then  why  does  formal  modelling  ever 
succeed?  The  reason  is  that  we  try  to  deploy  these  models  in  situations  where  the  inevitable  ontological  mismatches 
will  either  be  checked  or  will  have  negligible  impact  on  the  task  which  we  are  interested  in  performing.  In  the  ecological 
modelling  work  we  were  careful  to  avoid  building  into  the  model  generation  mechanism  any  heuristics  which  relied 
on  a  particular  interpretation  of  “biomass”  other  than  as  the  name  of  an  attribute  of  certain  objects  in  our  problem 
description.  The  price  we  paid  for  this  was  that  our  generator  couldn’t  provide  as  much  automatic  control  over  model 
construction  as  it  might  if  it  made  more  commitments  to  the  meaning  of  domain-specific  concepts.  We  gladly  paid 
this  price  in  order  to  avoid  the  project  foundering  on  arguments  about  the  domain  theory  which  (via  the  ontology) 
we  would  have  been  forced  to  embed  within  our  inference  system.  °’ ' 

4  Fitting  in  with  People  in  the  Domain 

A  well  known  problem  in  early  design  is  in  defining  who  will  be  expected  to  maintain  and  benefit  from  the  inference 
system  we  build.  For  the  purposes  of  this  paper  I  shall  ignore  that  problem  -  although  it  is  embarrassing  to  remember 
how  frequently  I  and  others  have  said  “the  user”  in  technical  papers  instead  of  some  more  enlightening  description  of 
the  people  expected  to  benefit  from  some  applied  system.  There  are  other  less  obvious  pitfalls  which  await  the  unwary. 

One  of  the  most  difficult  human  factors  to  control  in  a  research  project  of  more  than  a  few  months  duration  is  when 
to  acquaint  collaborators  in  the  domain  of  application  with  the  formal  methods  we  are  using.  It  has  been  said  (in  [4] 
for  example)  that  the  delay  in  seeing  a  return  for  an  investment  in  formal  methods  is  one  of  the  key  impediments  to 
their  success  in  industry.  I  suspect  this  is  true  in  applications  where  the  problem  is  clearly  identified  and  the  task  is 
to  describe  it  as  succinctly  and  precisely  as  possible.  In  this  situation  we  have  to  wait  until  the  end  before  we  have 
the  “complete”  result  which  is  required.  However,  in  early  design  we  are  much  more  likely  to  be  building  prototype 
systems  to  explore  what  the  tractable  problems  are.  We  then  have  to  choose  how  soon  we  want  to  have  these  ready. 
Simple  prototypes  can  occasionally  be  produced  extremely  rapidly.  The  fastest  I  have  ever  done  this  is  producing 
a  16-predicate  logic  program  to  demonstrate  inference  of  chemical  pathways  within  two  hours  of  meeting  a  group  of 
plant  microbiologists  for  the  first  time.  The  longest  time  to  release  a  prototype  is  roughly  two  years  for  a  system  we 
built  to  relate  codes  of  practice  to  a  safety  shutdown  system  built  using  paxameterisable  components  (see  [6]  for  an 
overview  of  this). 

Taking  too  long  to  release  a  prototype  can  cause  create  unpredictable  problems  because  in  that  length  of  time  the 
circumstances  of  industrial  partners  can  change.  For  example,  it  would  have  been  better  (with  hindsight)  to  have 
produced  more  quickly  a  less  impressive  prototype  system  for  the  safety  shutdown  domain  because  at  the  two  year 
point  our  industrial  collaborators  happened  to  be  under  greater  workload  than  hitherto,  so  they  had  less  time  to  spend 
with  us.  Longer  gestation  periods  give  more  opportunities  for  accidents  like  this  to  happen. 

On  the  other  hand,  very  rapid  prototyping  can  reuse  expectations  too  high.  Often  complicated  problems  contain 
a  sub-problem  which  is  easy  to  tackle  in  an  appropriate  inference  system.  To  those  with  little  experience  of  such 
methods  the  initial  results  can  seem  almost  magical  and  it  can  be  difficult  to  explain  that  other  essential  tasks  may 
be  orders  of  magnitude  more  difficult.  Without  careful  management,  a  fast  return  for  investment  can  be  as  damaging 
as  a  slow  return. 

Ironically,  rapid  prototyping  can  also  have  an  opposing  effect.  Prototypes  invite  (constructive)  criticism  and  domain 
experts  are  normally  good  at  spotting  what  they  don’t  like  or  would  wish  extended.  As  we  saw  in  Section  2,  it  is 
easy  to  feel  the  urge  to  increase  the  complexity  of  an  inference  system  and  the  feedback  from  early  prototypes  may 
increase  this  pressure.  Changes  in  support  systems  (such  as  visual  interfaces)  do  not  necessarily  change  in  harmony 
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with  th.6  core  inference  methods  so  relatively  small  char>o*»c  in  tVip  cfvio  c  •  c  . 

long  time  to  achieve  consensus  because  there  is  always  some  new  and  exciting  variant  to  build 

5  Education 

A  popular  way  to  make  inference  systems  accessible  to  non-logicians  is  by  providing  an  environment  whirh 
thos  non-logicians  understand  the  system  by  connecting  it  to  concepts  in  which  they  may  easily  be  trained  An 
example  is  techniques  editing  (attributable,  among  others,  to  [7]  with  a  survey  of  applications  in  [2])  which  rivest^ 
account  of  the  structure  of  logic  programs  in  terms  of  “conceptual  structures”  corresponding  to  tasks  sucht  tem 
decomposition  in  various  forms  via  recursion;  term  construction  and  so  on.  These  structural  patterns  apply  across  all 
t  e  clauses  in  predicate  and  follow  argument  position,  so  predicates  can  be  defined  argument  by  argument  according  to 

beent  if  rather  than i  building  clause  by  clause  or  in  some  more  serendipitous  way.  Stracture  editors  hive 

been  built  which  give  libraries  of  patterns  and  take  care  of  many  of  the  details  of  applying  them.  Conveniently  these 
patterns  also  correspond  to  the  way  predicates  are  described  when  teaching  logic  programming-  we  explain  that  a  given 

SfhTnTthattoT??  ItS  fSt  argUr?ent  and  constructs  a  term  in  its  second  ar^ment”  so  it  is  temping 

to  think  that  tools  like  this  help  non-logicians  learn  how  to  write  logic  programs.  A  group  of  psychologists  (then  at 

the  University  of  Loughborough)  led  by  Tom  Ormerod  ran  some  tests  comparing  the  performance  of  undergraduate 

u  ents  using  one  of  our  techniques  editors  within  a  Prolog  programming  course  to  a  similar  group  of  students  taught 

thos!  IZ7  r  6  ^  Th°Se  USiVhS  teChniqU6S  6dit0r  did  indeed  Write  appropriatf  deLitions  E 

ose  without.  However,  their  mnate  ability  to  understand  example  problems  in  logic  programming  terms  did  not 

usTth?  JITS'  ^  th0Se.W^°  Jadn,t  used  the  editor’  0ne  explanation  for  this  is  that  they  had  learned  to 
use  the  tool  to  build  solutions  quickly  but  hadn’t  learned  to  think  like  skilled  logic  programmers.  Sometimes  such 

nec®SSi “y  ■  we  may  want  the  inference  system  to  be  a  mystery  to  our  customers  because  it  would  merely 
distract  them.  The  pitfall  here  is  m  thinking  that  education  necessarily  comes  with  tool  support. 

Ah re  Jem;ciou®  (and  1  aspect  prevalent)  pitfall  occurs  when  we  consider  how  the  developers  of  inference  systems 
p  r)dUCat>d‘  if  1S,°ften,faSe.y  ascsumed  that  for  those  exPert  in  an  appropriate  logic  the  only  additional  training 

r™  f!iTain  f  !f  °f  d°mT  of  application  is  “  potato  crop  modelling  then  we  need  only  to  talk  with  potato 
crop  modellers  and  read  a  few  books  on  the  subject.  In  fact,  there  is  often  need  for  additional  training  of  the  logic 
experts  m  knowledge  representation.  This  is  because  much  of  the  teaching  of  logic  focuses  on  the  semantics  of  the 
chosen  iogic  and  its  proof  theory.  For  these  it  suffices  to  use  abstract  descriptions  such  as  P  -,0.  In  fact  it  is 
often  better  to  use  these  because  it  makes  abstract  notions  easier  to  see,  for  example  that  the  previous  expression  is 
equivalent  in  classical  logic  to  -.P  V  ->Q.  However,  this  sort  of  expertise  is  different  from  the  expertise  necessary  to 
decide  on  an  ontology  for  a  domain  and  apply  that  ontology  in  a  way  which  provides  elegant,  tractable  descriptions 
of  problems.  Both  forms  of  expertise  are  necessary  to  tackle  problems  but  not  all  experienced  logicians  are  good  at 
•  v-uf  representatl0n-  An  example  appears  in  Berry’s  article  in  these  proceedings.  Notice  that  the  sort  of  expertise 
in  w  ich  logicians  are  often  deficient  isn’t  the  sort  which  is  taught  simply  by  presenting  abstract  logic  differently  -  for 
instance  by  instantiating  the  logical  implication  above  to  penguin  -+  -.flies.  These  are  additional  skills,  such  as  the 
ability  to  choose  good  idealisations  of  problems,  which  are  not  guaranteed  by  an  aptitude  for  abstract  logic. 


6  Evaluation 

In  research  projects  involving  the  construction  of  experimental,  applied  inference  systems  we  need  some  form  of 
evaluation  to  assess  what  sorts  of  applied  problems  can  be  tackled  with  the  system  and  (if  we  are  making  usability 
claims)  how  easily  it  can  be  used  by  those  who  work  in  the  domain.  We  must  then  worry  about  the  cost  of  the 
evaluation  effort;  the  degree  to  which  empirical  evaluation  is  likely  to  yield  meaningful  results;  and,  in  the  most 
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extreme  case,  whether  it  is  possible  for  our  system  to  fail  (that  is,  whether  we  are  doing  an  experiment  at  all).  In  each 
if  these  three  cases  the  fact  that  we  are  evaluating  an  inference  system  can  raise  special  difficulties. 

Empirical  evaluation  is  normally  costly  for  any  software  implementation  but  inference  systems  are  often  particularly 
expensive  to  evaluate  because,  even  if  we  do  our  best  to  fit  them  into  standard  work  practices,  they  give  people  new 
ways  of  doing  their  jobs.  Describing  ecological  systems  in  a  domain-specific  formal  language  [13,  3]  was  new  to  those 
who  tested  our  model  generation  systems.  Describing  shutdown  systems  using  parameterisable  components  in  the 
way  described  in  [6]  is  new  to  most  safety  engineers.  This  makes  it  difficult  to  relate  old  to  new  work  practices. 
If  the  inference  system  has  not  been  embedded  carefully  within  its  host  organisation  then  it  may  rated  poorly  just 
because  it  was  badly  introduced.  If  it  is  cosseted  too  carefully  during  field  trials  then  its  rating  may  be  artificially 
high.  Attempting  to  get  this  right  takes  time  and  money.  For  example,  in  the  evaluations  mentioned  in  Section  5  we 
were  interested  in  comparing  student  performance  in  Prolog  programming  with  and  without  a  techniques  editor.  Both 
groups  of  students  (with  or  without  the  editor)  needed  to  be  taught  Prolog.  To  avoid  artificially  boosting  the  editor’s 
performance  because  it  was  being  introduced  by  those  who  built  it,  the  Prolog  courses  and  accompanying  testing 
had  to  be  done  by  other  researchers  (in  another  University).  To  avoid  a  misfit  between  the  editor  and  the  Prolog 
training  course  it  was  necessary  to  construct  a  variant  of  the  original  course  into  which  the  editor  was  dovetailed.  To 
allow  comparison  between  techniques  editor  and  text  editor  courses  some  retrospective  adaptatation  of  the  original 
course  was  needed.  All  of  this  takes  considerable  effort  beyond  that  of  the  evaluation  experiments  themselves,  and  our 
example  concerns  an  inference  system  which  was  built  in  order  to  be  tested  this  way.  Frequently,  the  costs  of  carefully 
controlled  evaluation  can  be  much  higher. 

Given  the  difficulty  and  cost  of  controlled  evaluation  it  is  little  wonder  that  there  are  few  (if  any)  extensive  usability 
evaluations  of  larger  inference  systems.  An  alternative  is  to  identify  parts  of  the  system  and  evaluate  those.  Here  we 
meet  at  least  another  two  pitfalls  for  those  using  logical  inference  systems.  It  is  standard  practice  to  develop  these 
systems  in  a  modular  way  so  that  the  (internal)  inference  mechanisms  are  separable  from  but  interacting  with  the 
(external)  user  interface.  This  can  make  it  difficult  to  judge  whether  some  faults  turned  up  by  evaluation  could  easily 
have  been  corrected  by  some  adjustment  to  either  (or  both)  parts  of  the  system.  Perhaps  a  more  serious  pitfall  is 
in  assuming  that  evaluation  is  compositional,  in  the  sense  that  we  can  evaluate  part  of  a  system  then  combine  that 
with  evaluations  of  other  parts  to  form  a  broader  evaluation.  This  is  seldom  possible,  even  if  our  inference  system 
is  compositional,  for  two  reasons.  First,  if  the  separately  evaluated  components  have  user  interfaces  then  we  must 
ensure  that  a  good  interface  for  one  is  consistent  with  a  good  interface  in  the  other  which  may  not  be  the  case  if 
they  require  modes  of  communication  which  are  mutually  antagonistic.  For  example,  we  might  have  a  good  usability 
evaluation  for  a  sub-system  which  displays  a  graphical  proof  tree  and,  separately,  a  good  evaluation  of  a  sub-system 
which  displays  structured  terms  in  a  similar  graphical  style  but  when  these  are  combined  we  get  a  poor  usability 
evaluation  because  people  are  confused  by  the  uniform  visual  representation  of  different  formal  concepts.  The  second 
form  of  compositionality  problem  is  created  by  changes  in  demand  for  the  system  as  we  consider  the  broader  lifecycle 
of  which  it  must  be  a  part.  For  instance,  we  are  reasonably  confident  from  our  evaluations  of  novice  programmers  that 
techniques  editors  fit  well  into  Prolog  training  courses.  However,  this  does  not  mean  that  eventually  techniques  editors 
will  be  part  of  all  introductory  Prolog  courses  because  for  that  to  happen  it  would  be  necessary  for  them  to  mesh  with 
the  other  tools  which  more  experienced  Prolog  programmers  want  to  use.  Our  limited  evaluation  says  nothing  about 
that. 

Ironically,  the  success  of  logicians  in  producing  expressive  and  internally  consistent  formal  languages  makes  it  easy 
for  engineers  to  fall  into  the  trap  of  designing  “evaluation  experiments”  which  are  not  experiments  at  all  because  there 
is  no  possibility  of  failure.  Some  examples  of  questions  for  which  the  answer  will  almost  certainly  be  “yes”,  given 
enough  effort  and  an  expressive  formal  language  axe: 

•  Can  a  problem  tackled  in  system  X  be  tackled  by  a  (similar)  system  V?  The  answer  will  be  “yes”  if  we  work 
hard  enough  with  system  Y.  This  question  is  rather  like  comparing  programming  languages  -  only  interesting  if 
we  can  compare  the  degree  of  difficulty  on  clearly  defined  problems. 

•  Can  system  Y  be  made  to  work  better  than  system  X  on  a  given  problem?  The  answer  will  be  “yes”  if  we  are 
allowed  unlimited  adaptation  of  system  Y.  This  is  interesting  only  if  the  changes  to  Y  axe  carefully  constrained. 

•  Can  people  be  trained  to  use  system  XI  They  almost  certainly  can  if  we  choose  them  carefully  and  give  them 
enough  resource  and  incentives.  The  interesting  question  is  whether  the  people,  resources  and  incentives  are 
available  in  any  real  domain. 
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.  Will  people  become  better  at  solving  task  T  using  system  X?  If  task  T  is  of  interest  and  system  X  is  relevant 
and  people  use  it  then  they  are  very  likely  to  get  better  at  the  task  just  because  they  are  getting  practice  (see 
Berry  s  comments  on  the  second  time”  phenomenon  in  this  proceedings).  The  interesting  question  is  whether 
they  get  better  faster  than  they  would  have  done  by  normal  means. 

None  of  the  above  are  necessarily  the  wrong  thing  to  do.  The  pitfall  here  is  in  thinking  of  these  as  giving  some 

usefui  measure  of  empirical  fitness  of  the  method  without  controlling  the  conditions  under  which  the  measure  was 
obtained. 


7  Conclusions 

Mathematical  method  is  a  prerequisite  to  precise  experimental  method.  However,  the  former  does  not  guarantee  the 
latter.  In  preceding  sections  I  have  given  examples  of  mistakes  which  mathematical  method  alone  cannot  help  us  to 
avoid.  These  are  summarised  below: 

•  The  choice  of  inference  system  often  changes  during  a  project  and  this  requires  either  alteration  of  the  current 
inference  machinery  or  its  substitution  by  a  new  system.  It  can  be  difficult  to  make  the  right  choice  of  specialist 
inference  system  and,  even  if  it  is  the  right  choice,  there  can  be  high  cost  in  re-education  of  co-researchers  which 
accompanies  each  change.  Too  many  such  changes  cause  failure  to  a  project  because  of  the  cumulative  cost. 

•  The  cost  of  producing  an  ontology  is  not  just  in  inventing  the  domain-specific  formal  language  but  in  maintaining 
it  once  the  system  is  deployed,  since  perfect  ontologies  cannot  be  guaranteed.  Over-commitment  to  perfecting 
an  ontology  causes  failure  either  during  development  (through  irireconcilable  arguments  over  what  the  ontology 

should  be)  or  after  deployment  (through  inappropriate  human  interpretation  of  inference  system  inputs  or 
outputs). 

•  Formal  methods  are  often  criticised  because  they  take  too  long  to  yield  results  but  this  isn’t  necessarily  true  in 
early  design.  Ironically,  problems  such  as  inflated  expectations  and  perpetual  prototyping  can  be  caused  by  the 
ability  of  some  inference  systems  to  tackle  isolated  parts  of  problems  rapidly. 

•  Education  is  required  to  bring  logicians  and  domain  specialists  closer  together.  We  sometimes  assume  that 
the  tools  we  produce  will  help  educate  domain  specialists  and  that  training  in  abstract  logic  is  enough  formal 
preparation  for  tackling  problem  domains.  Both  assumptions  can  be  false. 

•  Through  force  of  circumstance  or  naivete  we  may  under-evaluate  our  systems,  because  we  can’t  afford  the  cost; 
or  we  lack  a  framework  for  structuring  the  evaluation;  or  because  our  programme  of  research  was  not  in  essence 
experimental. 
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complex  automation  processes  controlling  e  e  a  chemical  nmdnrfinn°  i  ,  ’-r  .  senc{  shutdown  and  gas  detection,  but  also 

5ST  prMi“’  d“a,c  ——  - 

Keywords 

1  INTRODUCTION 

Programmable  logic  controllers  (PLCs)  are  forming  a  growing  market  of  special  purpose  hybrid  systems  integrating  micro 

=SS5 

The  rapid  development  of  PLC  systems  in  the  eighties  led  to  a  wealth  of  incompatible  vendor-specific  PLC  orooramminc 
response  toTh  ‘n  . jj16  proce®s  :ndustries  impeding  the  design  of  more  complex,  open  and  distributed  control  applications  In 
unZ  rcvtXT  mc  m  “SZTT  T*?  6U?'3  ^  PLC  pr0SramndnS  H4]  was  developed  and  is  currently* 

engineers  look  at  industrial  control^ys^^^di^n^thepr^rami^nginterfai^3111111^^6  C0ntr0^ers  and  harmonizes  the  way 

dementsT181  Th^J  “  ***  °r  ^  pUIP0Sftuilt  Ian«uaSes  «*at  overlap  conceptually  and  share  a  subset  of  programming 

Ch^t  fSFO  hav^a  TT S  Z’ FUnCd0n  BI°Ck  Diagfam  (FBD)’ Udder  D^gram  (LD)  and  Sequential  Function 

for^eph^ng^seauenfiafhclf  appeafance'  supports  component-based  application  programming,  while  SFC  is  mainly  used 

P  g  SCqUential  behavior  of  a  contro1  system  including  alternative  and  parallel  execution  sequences. 

tharwT^incri?  P.L?'  the  comf°rt  °f  the  PLC  languages,  and  strong  economical  demands  led  to  the  current  situation 

Ex“™to1nclJdS  7  7  P^C-based.sys.,e,“  fOT  «"«»' “>d  automation  functions  in  safety-related  applications. 

—(  1  “*fBc  “ntr°'' .  patient  monttonng,  process  automation,  e.g,  in  chemical  industry,  emergency  shut  down 
systems  m  power  generation,  and  production  line  control.  ^ 

desiggneTtLarWveSS  °f  °Ur  °f  need  t0  pr°teCt  *e  environment,  a  higher  sensitivity  to  accidents  caused  by  ill- 

designed  technology  or  processes,  and  a  declining  trust  m  marketing  statements  of  manufacturers  produce  an  enormous  pressure 

*1998 
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to  increase  the  dependability  of  safety  related  applications.  In  practice,  however,  we  observe  that  rigorous  proof  techniques  and 
robust  tools  that  can  be  used  effectively  by  practitioners  in  industry  and  regulatory  authorities  and  in  the  application  domain 
are  not  available.  Existing  design  guidelines  and  testing  practices  may  help  to  detect  design  and  programming  errors  but  they 
cannot  guarantee  the  absence  of  faults  that  may  cause  a  disaster  because  exhaustive  testing  limited  to  rare  cases. 

In  the  main  body  of  this  paper  we  explore  function  blocks  —  which  represent  the  engineer’s  idea  of  re-usable  ’’software  ICs”  — 
and  sequential  function  charts  to  develop  a  modular,  theorem  prover-based  verification  framework.  By  taking  components  from 
application-specific  libraries  of  verified  standard  function  blocks,  the  verification  of  new  applications  is  reduced  considerably 
because  only  the  correctness  of  the  composition  has  to  be  established  for  each  new  application. 

In  the  following  section  we  introduce  core  concepts  of  FBD  andSFC.  In  Section  3  we  argue  about  the  logic  and  theorem  proving 
assistant  used  to  verify  functional  correctness  and  safety  of  individual  function  blocks  and  complete  control  applications  built 
from  such  components.  This  verification  process  can  be  automated  by  a  semantic  embedding  of  the  selected  PLC  languages 
into  that  logic.  This  embedding  is  explained  in  Section  4,  while  our  verification  approach  and  the  challenges  of  handling 
complex  continuous  systems  are  sketched  in  Section  5  and  Section  6.  We  conclude  with  a  brief  summary  and  an  outlook  on 
an  industrial  strength  verification  tool  that  is  to  build  on  this  or  a  similar  verification  framework  and  can  ultimately  be  used  by 
domain  experts  with  little  or  no  expertise  in  software  verification. 

2  FUNCTION  BLOCKS  AND  SEQUENTIAL  FUNCTION  CHARTS 

Function  blocks  are  program  organization  units  with  a  private  state  that  persists  from  one  invocation  to  the  next.  A  function 
block  interacts  with  its  environment  primarily  via  input  and  output  variables.  The  standard  also  allows  global  variables  but 
our  verification  framework  does  not  support  these.  Besides  keeping  the  semantics  simple,  this  also  has  the  advantage  that  the 
execution  of  function  blocks  has  no  side-effects. 

From  a  semantic  point  of  view,  function  blocks  are  a  special  case  of  deterministic  reactive  modules  [1].  According  to  the  model 
of  reactive  systems  [9],  their  execution  takes  place  in  a  sequence  of  rounds.  At  the  start  of  each  round,  the  input  variables  are 
read.  This  is  followed  by  an  update  of  the  private  and  output  variables.  This  update  is  functionally  dependent  on  the  current 
value  of  the  input  variables  and  the  previous  state  of  the  private  and  and  output  variables. 

The  description  of  a  function  block  can  be  split  into  the  declaration  of  its  external  interface  and  a  specification  of  the  internal 
implementation.  The  former  is  part  of  the  function  block  signature  that  specifies  the  types  and  names  of  variables  including 
local  instances  of  function  blocks.  In  the  context  of  graphical  representations,  the  input  and  output  variables  will  also  be  referred 
to  as  ports.  The  interface  specification  is  similar  to  the  description  of  interfaces  in  other  languages  such  as  CORBA-IDL  [8]. 
The  internal  implementation  of  a  function  block  body  can  be  carried  out  in  any  of  the  five  IEC  61131-3  programming  languages 
or  even  in  other  languages  such  as  C  or  Java. 

As  an  example,  Figure  1  (a)  shows  a  graphical  representation  of  the  external  interface  of  the  function  block  DEBOUNCE  taken 
from  the  IEC  61 131-3.  DEBOUNCE  has  two  input  variables  IN  and  DB.TIME  of  type  BOOL  and  TIME  and  two  output 
variables  OUT  and  ET.OFF  of  the  same  types. 


DEBOUNCE 
I  IN  OUT! 


BOOL 

TIME  — |DB_TIME  ET_OFF 

(a)  External  interface 


h-  BOOL 
TIME 


IN 


DB_ON 


DB_T1ME 


DB_FF 


OUT 


ET  OFF 


(b)  Implementation  as  function  block  diagram 


Figure  1:  Function  block  DEBOUNCE 

An  implementation  of  DEBOUNCE  as  a  function  block  diagram  is  depicted  in  Figure  1(b).  The  function  blocks  DB.ON  and 
DB.OFF  are  two  separate  instances  of  the  timer  function  block  TON,  while  DB  JFF  is  an  instance  of  the  SR  flip-flop  included 
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.n  the  standard.  By  connecting  input  and  output  ports,  a  diagram  is  “wired  together”  from  the  components.  As  in  the  graphical 
representation  of  circuits,  at  the  open  circle  such  as  at  the  input  port  IN  of  DB.OFF  indicates  the  negation  o7a  Boolean 

“  °f  fUnC?0n  bl0CkS  Wil1  USUally  als0  be  referred  t0  simP{y  35  hnc'ion  blocksSnie  function  block 
mEH°TnhE  15  C°rP°Sed  from  Sta.ndard  fbncti0n  bl0cks  Predefined  in  the  norm.  Such  a  composite  function  block  can  itself  be 

fcSXks”' fi"'CU0"  b,°CkS-  “*  U  ““  foc  ***•  - 


DB.ON  (IN  :=  IN,  PT  :=  DB.TIME); 
DB.OFF  (IN  :=  NOT  IN,  PT  :=  DB.TIME); 
DB  JT  (S  :=  DB.ON.Q,  R  :=  DB.OFF.Q); 
OUT  :=  DB_FF.Q; 

ET.OFF  :=  DB.OFF.ET; 


Figure  2:  DEBOUNCE  in  Structured  Text 


The  second  graphical  language  of  the  standard,  SFC,  can  be  regarded  as  an  application  of  Petri  nets.  Its  language  concepts 
include  transitions,  steps  and  actions.  They  serve  to  co-ordinate  the  execution  of  function  blocks  that  are  regarded  as  asyn¬ 
chronous  sequential  processes.  3 

To  illustrate  the  role  of  SFC,  we  refer  to  a  small  laboratoiy  plant  that  has  been  used  previously  as  a  benchmark  for  non-linear 
control  design  methods  [13]  and  for  the  tool-aided  analysis  of  discretely  controlled  continuous  systems  [15].  The  plant  features 
two  cylmdric  tanks  that  are  located  at  different  levels.  The  tanks  are  equipped  with  three  pipes  and  three  valves  controlling  the 
flow  of  liquid  between  the  tanks,  at  the  inlet  and  at  the  outlet  (see  Fig.  3(a)).  The  pipes  are  controlled  by  valves  V0,  Vx  and 
V2.  The  liquid  level  in  the  second  tank  is  measured  by  a  sensor  L.  A  core  safety  requirement  for  this  application  is  to  avoid 
overflow  in  the  coupled  tank  system. 
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(b)  SFC  controller 
Figure  3:  Laboratory  plant  with  SFC  controller 


The  SCF  depicted  in  Fig  3(b)  controls  the  behavior  of  the  system.  It  consists  of  five  steps  sO, ...  s4.  The  actions  connected 
with  the  steps  control  the  state  of  the  valves:  the  qualifiers  S  and  R  denote  setting  and  resetting  of  an  action,  respectively.  The 
transitions  separating  the  steps  are  enabled  by  Boolean  valued  expressions  that  reflect  conditions  on  the  state  of  the  associated 
function  block. 
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The  encapsulation  provided  by  function  blocks  together  with  their  openness  with  respect  to  the  internal  implementation  furthers 
the  reuse  of  function  blocks  in  different  applications.  Hence,  it  makes  sense  to  develop  component  libraries.  Examples  include 
the  collection  of  standard  function  blocks  of  the  IEC  61131-3,  the  German  standard  norm  [30],  and  the  domain  specific  library 
of  function  blocks  used  by  a  German  manufacturer  of  chemicals  and  drugs  we  have  studied  earlier.  This  in-house  library 
consists  of  about  70  function  blocks  that  are  sufficient  to  specify/program  chemical  process  automation  tasks. 

3  HIGHER  ORDER  LOGIC  FOR  VERIFICATION 

The  basic  logic  underlying  our  verification  approach  is  higher  order  logic  [3, 7].  There  are  several  good  reasons  for  this  choice: 

1.  The  means  of  abstraction  and  quantification  over  functions  make  this  logic  very  expressive  and  thus  well  suited  to  the 
concise  description  of  complex  theories.  Evidence  of  this  fact  is  provided  by  the  embedding  of  hardware  description 
languages  [4]  and  the  verification  of  floating  point  algorithms  [12]. 

2.  HOL  is  a  widely  studied  and  well  understood  logical  system  with  a  remarkably  small  number  of  axioms  and  inference 
rules.  Its  expressiveness  makes  it  possible  to  use  definitional  extension  as  the  principal  method  of  theory  development. 
Since  this  method  is  conservative,  logical  inconsistencies  can  be  practically  ruled  out. 

3.  Automatic  type  inference  systems  for  HOL  make  type  annotations  to  a  great  extend  unnecessary.  This  shortens  formulas 
and  proofs  because  the  information  contained  in  the  typing  is  automatically  inferred  and  propagated. 

In  comparison  to  alternatives  sqch  as  Zermelo-Frankel  set  theory,  there  are  also  a  few  disadvantages: 

1.  The  type  discipline  of  HOL  leads  to  a  certain  loss  of  flexibility,  cf.  [17].  This  statement  remains  true  despite  the  expres¬ 
siveness  of  polymorphism  and  symbol  overloading  available  in  systems  such  as  Isabelle/HOL. 

2.  In  comparison  with  first  and  second  order  logics,  the  implementation  of  the  HOL  type  system  is  technically  more  de¬ 
manding.  In  particular,  the  existence  of  type  and  function  variables  complicates  unification,  the  basic  method  of  equation 
solving  [22].  Also,  most  research  in  automated  theorem  proving  has  been  performed  in  the  area  of  first  order  theories. 

For  our  purpose,  the  advantages  of  HOL  outweigh  these  drawbacks.  Its  extendibility  makes  it  unnecessary  to  introduce  special 
logics  for  the  definition  of  the  semantics  of  programs  and  specifications.  Instead,  HOL  provides  a  logical  core  that  can  serve  as 
the  common  semantical  basis  for  a  range  of  different  formalisms. 

Furthermore,  it  is  important  that  the  logic  is  supported  by  several  reliable  and  efficient  mechanical  theorem  proving  assistants. 
Our  system  of  choice  is  the  object  logic  HOL  of  the  generic  theorem  proving  assistant  Isabelle  [25].  Like  the  HOL  system  [7]’ 
Isabelle  builds  on  the  functional  programming  language  SML  [20],  Noteworthy  alternatives  include  the  HOL  system  and  the 
LISP  based  PVS  [27]  system. 

With  regard  to  verification,  the  high  degree  of  safety  and  reliability  of  a  proof  assistant  are  of  paramount  importance.  In  the 
Isabelle  system,  a  number  of  measures  are  taken  in  order  to  achieve  this  aim: 

1.  Theorems  are  elements  of  a  special  abstract  SML  data  type  thm.  New  elements  of  this  type  can  only  be  formed  by  a 
small  number  of  operations  representing  valid  logical  deductions  or  explicit  axioms.  If  one  assumes  that  the  Isabelle 
implementation  of  these  basic  operations  is  correct,  then  the  static  type  checking  of  SML  guarantees  also  the  logical 
validity  of  all  derivations. 

2.  The  preferred  method  for  extending  theories  is  definitional.  This  minimizes  the  danger  of  logical  inconsistencies. 

3.  Isabelle  is  an  open  and  extendible  system  with  a  freely  available  source  code.  The  source  code  is  well  structured  and  written 
in  a  functional  programming  language  with  only  little  use  of  imperative  features.  This  makes  it  open  to  be  scrutinized  by 
independent  researchers. 

Furthermore,  Isabelle  has  a  comprehensive  international  user  community.  These  combined  factors  have  given  Isabelle  -  like  the 
HOL  system  -  the  reputation  of  an  extremely  trustworthy  proof  support  system. 

In  addition  to  safety,  a  high  degree  of  proof  automation  is  essential  in  order  to  cope  in  a  reasonable  time  with  the  many  proof 
obligations  arising  during  verification.  The  main  tools  of  the  Isabelle  systems  in  this  respect  are  a  term-rewriting  simplifier 
and  a  proof  search  tool  called  the  classical  reasoner.  External  decision  procedures  can  be  invoked  from  Isabelle  using  an 
oracle  mechanism.  The  degree  of  automation  is  sufficient  for  the  definition  of  formal  semantics  and  the  verification  of  small  to 
medium-sized  function  block  applications. 
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4  THE  EMBEDDING  OF  FUNCTION  BLOCKS  IN  HOL 

concentrated  up-,o  now  on  particular  aspec^of  re^I^ograin^ng'languag^such^the'type  safccy'tfa  Java'subset^S]!*1  ^ 

The  foundation  of  our  verification  framework  is  a  HOL  embedding  of  a  subset  of  Structured  Text  r«m  Th.  , 

this  embedding  cm,  be  fonndin  [3.J.  I,  is  a  teiativeiy  deep  embedding,  w,2 

assignment  of  semantics  are  represented  explicitly  in  HOL.  Semantics  are  defined  via  evaluation  functions  for  the  four  hhS  ^ 
syntactical  categories,  namely  expressions,  statements,  functions  and  function  blocks.  As  a  result,  every  function  bleckh 
associated  with  a  deterministic  but  not  necessarily  finite  Mealy  automaton  in  HOL.  Time  is  treated  as  an7nput  variable  Like 

constant  in  each  round-  ™s  *■  ** ^ 

J?*  ?0L  term.S.that  descnbe  tbe  semantics  of  function  blocks  are  initially  cluttered  with  occurrences  of  the  evaluation  functions 
In  a  term  rewriting  process  which  resembles  a  symbolic  evaluation,  these  occurrences  can  be  eliminated  This  process  can  hP 

largely  automated.  It  yields  HOL  terms  that  resemble  simulations  of  ST  function  blocks  viewed  as  functional  programs  In  this 
form,  the  automata  are  suitable  for  verification.  programs,  in  this 


An  important  aspects  of  our  semantics  is  compositionality.  This  means  that  the  transition  function  of  the  automaton  belonging 
to  a  composed  block  is  a  composition  of  the  transition  functions  of  the  automata  belonging  to  the  components  Thus  proved 
properties  of  the  components  can  be  reused.  Furthermore,  by  abstracting  over 

properties  of  composed  function  blocks  without  reference  to  the  concrete  implementation  of  the  Components  P  P 

PRndLti0n.t0.ST’OUr  verification  framework  also  deals  with  subsets  of  the  two  graphical  IEC 61 131-3  languages  SFC  and 
FBD.  This  is  based  on  interpretations  of  these  two  formalisms  in  ST.  The  result  is  in  both  cases  a  formal  s°emfntics  that  is 
sequential  and  deterministic.  We  will  sketch  the  interpretation  of  function  block  diagrams  below.  For  SFC,  we  refer  to  [31]. 

Interpretation  of  F unction  Block  Diagrams  in  ST 

"“V “P“B in *■' <lia*ra,n induces; “ relation. onto  components:  a  function 
*  r  I  i  fU"C"™  bock,B  Prov,ded  “ '=“> °»« inp»t  port  of  A  is  connected  directly  or  indirectly  to  some  output 
port  of  B.  The  relation  is  a  partial  order  as  long  as  the  diagram  does  not  contain  feedback  loops  such  as  in  Fig  4(a)  In  the  latter 
case  we  require  the  user  to  specify  feedback  variables  for  connections.  This  has  the  effect  of  a  unit  delay  on  the  connections 

relat  Mfo'r funrhf-  ‘"IT  rec.%ves  the  °Utf>Ut  Value  fr0m  the  previous  round-  In  the  definition  of  the  dependency 

r  the  interPretation  of  a  funct‘on  block  diagram  in  ST  is  a  sequentialization  of  the  function  block  executions 
per  round.  The  only  requirement  placed  on  this  sequentialization  is  its  compatibility  with  the  dependency  ordering  This  rule 

hnri!  nn  om  '  ^nDnm!6”'10"  0fder  °f  indePendent  function  blocks.  For  example,  in  the  function  block  DEBOUNCE, 
both  DB.ON  and  DB  OFF  have  to  be  executed  before  DB _FF,  but  nothing  is  said  about  their  relative  execution  order.  Since  we 

thTricl-  °ba  Vanab  eS'n  f  venficatl0n  framework,  this  under-specification  does  not  lead  to  non-determinism;  in  addition, 
he  resulting  semantics  of  a  function  block  is  not  affected  by  the  choice  of  execution  sequence  as  long  as  it  is  compatible  with 


A  chosen  execution  order  can  be  translated  directly  to  a  sequence  of  ST  function  block  invocations.  This  is  followed  by  updates 

°f  .Tcoo?  a0t.d  °Ut.pUt  vanab,es-  FiSure  4(b)  exemplifies  this  for  the  case  of  the  SR  flip-flop.  Here,  feedback  variables  FBI 
ana  have  been  introduced  for  the  connections  from  Nl.OUT  to  N2.IN1  and  N2.0UT  to  N1.IN2. 

5  THE  VERIFICATION  APPROACH 

The  deep  embedding  of  PLC  programming  languages  in  HOL  provides  a  formal  semantics.  Furthermore,  the  semantics  given 
above  are  operational.  Function  blocks  can  thus  be  evaluated  symbolically  using  a  term  rewriting  tool.  Requirements  on  the 

*  SSv  1 fU.nCtL°,n  b,l0CkS  C3n  bC  translated  t0  H0L  Predicates  and  proven  formally.  Figure  5  shows  the  verification  process 
tor  oFL  function  blocks  using  linear  time  temporal  logic  (LTL,  [19])  as  specification  language. 

One  of  the  strong  points  of  the  HOL  based  approach  is  its  openness  with  respect  to  possible  extensions.  An  addition  of  further 
programmmg  or  specification  language  constructs  is  unproblematic  as  long  as  it  does  not  affect  the  underlying  semantical  model 
ot  the  already  embedded  language  parts.  The  same  remark  holds  for  the  modeling  of  machine  or  environment  aspects,  which 
might  be  necessary  for  the  verification  of  more  complex  systems.  To  put  it  more  generally:  HOL  serves  as  logical  glue  that 
connects  different  programming  and  specification  formalism  and  allows  their  integration  and  analysis  within  one  framework. 
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(a)  SR  flip-flop  in  FBD 


N1  (INI  :=  S,  IN2  :=  FB2); 
N2  (INI  :=  FBI,  IN2  :=  R); 
FBI  :=  Nl.OUT; 

FB2  :=  N2.0UT; 

Q'  :=  FBI; 

Q  :=  FB2 


(b)  SR  flip-flop  in  ST 


Figure  4:  Function  block  with  feedback  loop 


External  tools: 
model  checkers, 
simulators, 


Figure  5:  Function  Block  Verification  Process 


147 


It  might  be  interesting  to  investigate  the  integration  of  the  Step  system  developed  by  Zohar  Manna’s  group  in  Stanford  with 
the  framework  used  here.  Especially  their  combination  of  model  checking  and  theorem  proving  might  be  advantageous  for  the 
application  domain  considered  in  this  contribution. 

In  relatively  small  examples  such  as  the  verification  of  a  liquid  container  controller  presented  in  [16],  the  standard  Isabelle/HOL 
proof  tools  are  sufficient.  Because  specifications  are  mapped  to  predicates  on  streams,  the  basic  proof  principle  is  induction 
over  the  natural  numbers.  In  the  induction  step,  the  validity  of  a  statement  in  round  (n  +  1)  has  to  be  derived  from  its  validity 
in  round  n.  Induction  is  also  essential  for  the  proof  of  auxiliary  algebraic  equalities  and  inequalities  and  the  verification  of 
iterated  structures  such  as  a  generic  adder.  Other  frequent  proof  techniques  are  case  distinctions,  algebraic  simplifications  and 
arithmetic  estimations.  Isabelle’s  classical  reasoner  has  been  very  useful  for  the  automation  of  these  kinds  of  proofs. 

For  more  complex  applications,  a  higher  degree  of  proof  automation  is  essential.  This  starts  off  with  the  automated  translation  of 
function  blocks  into  Isabelle  theories.  Tactics  specially  adapted  to  programming  or  specification  language  constructs  should  be 
tried  automatically  or  offered  interactively  to  the  user  for  selection  and  parameterization.  Relevant  automated  proof  procedures 
include  the  symbolic  model  checking  of  finite  systems  [2]  and  algorithms  for  establishing  program  invariants  [28, 10]. 

6  THE  CHALLENGE  OF  COMPLEX  DYNAMICS 

Up-to  now,  the  use  of  theorem  prover  based  tools  has  been  restricted  to  the  verification  of  systems  with  relatively  simple 
continuous  dynamics.  This  is  partly  due  to  the  fact  that  the  treatment  of  such  systems  would  require  extensive  real/complex 
analysis  libraries.  As  the  pioneering  work  in  [11]  shows,  this  is  a  comprehensive  task.  Even  with  such  libraries,  a  complete 
analytic  verification  of  systems  such  as  the  two  tank  laboratory  plant  sketched  in  Fig.  3  seems  a  daunting  task. 

Besides  providing  formal  models  of  controllers  and  abstractions  of  plant  properties,  one  useful  role  for  deductive  proof  tools  in 
this  area  might  be  the  validation  of  interpolation  and  extrapolation  properties.  These  guarantee  that  nothing  unexpected  happens 
for  parameter  combinations  that  have  not  been  explicitly  covered  during  simulation  or  model  checking.  This  validates  intuitive 
worst-case  reasoning  and  increases  the  trustworthiness  of  verification  results. 

7  TOWARDS  AN  INDUSTRIAL  STRENGTH  TOOL 

In  the  main  body  of  this  paper  we  presented  a  theorem  prover  based  flexible  verification  technique  that  supports  modular  proofs 
of  PLC  programs  expressed  in  FBD,  SFC  and  ST.  In  general,  the  development  of  such  proofs  with  the  help  of  theorem  prover 
assistants  requires  high  skills  from  the  quality  assurance  personnel  because  the  proof  assistant  relies  on  sophisticated  user 
guidance.  These  skills  cannot  be  expected  from  engineers  in  the  field. 

Conversely,  people  with  skills  in  formal  specification  and  verification  techniques  normally  lack  the  domain  expertise  needed  to 
understand  functional  and  safety  requirements  that  are  often  not  made  explicit  and,  if  so,  are  usually  presented  in  an  incomplete, 
ambiguous  and  informal  manner.  In  the  course  of  our  work  with  the  IEC  standard,  its  German  counterpart,  and  the  in-house 
standard  and  function  block  library  of  a  manufacturer  in  chemical  industry  we  spent  days  and  weeks  in  reading  through  these 
documents  and  many  hours  talking  to  domain  experts  to  fully  understand  the  requirements. 

Hence,  to  make  the  verification  approach  we  presented  work  in  automation  practice,  we  need  to  find  effective  means  to  solve 
the  following  three  tasks: 

1 .  Comprehensive  elicitation  of  functional,  safety,  and  -  if  appropriate  -  timing  requirements. 

2.  Formalization  of  these  requirements  in  a  suitable  logic. 

3.  Correctness  proof. 

As  the  set  of  standard  function  blocks  that  are  typically  used  in  specific  control  domains  ranges  between  50  and  a  few  hundreds 
and  the  complexity  of  the  majority  of  function  blocks  maintained  in  the  domain  library  is  relatively  low,  the  effort  to  have  these 
tasks  performed  by  computer  theoreticians  is  acceptable.  It  needs  to  be  summoned  up  only  once. 

However,  for  handling  individual  control  applications  that  are  composed  of  networks  of  function  blocks,  we  need  to  wrap  an 
open  verification  environment  with  a  front-end  that  is  usable  by  domain  experts.  This  verification  environment  may  build  on 
a  theorem  prover  as  its  backbone  and  comprise  other  tools  such  as  model  checkers,  simulators  or  computer  algebra  systems. 
The  interface  to  the  front-end  must  be  capable  to  elicit  enough  facts  about  critical  application  requirements  through  a  series  of 
communication  interactions  with  domain  experts  such  that  formal  requirement  statements  can  be  derived.  Such  dialogs  need  to 
know  about  the  terminology  of  the  field,  they  may  rely  on  a  collection  of  known  requirements  typical  for  that  domain,  and  they 
may  exploit  proven  properties  of  function  blocks  connected  to  the  application  interface  and  the  inner  wiring  of  the  application 
program  to  conduct  that  dialog.  It  may  also  exploit  paraphrasing  capabilities  to  verify  the  adequacy  of  formalized  requirement 
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statements  acquired  in  earlier  communications.  The  work  on  knowledge  intensive  software  engineering  tools  conducted  by  Rich 
and  Waters  (cf.,  e.g.  [26])  might  provide  prototype  solutions  for  the  engineering  environment  sketched  here.  In  a  related  project 
in  South  Africa,  we  have  also  used  Pamas’  table  specification  technique  [24]  to  formalize  standard  function  block  interfaces 
[2 1]  in  a  way  that  might  be  more  readable  to  engineers. 

To  facilitate  the  verification  task,  it  is  very  important  to  find  proof  patterns  and  reusable  proof  strategies  to.automate  recurring 
verification  steps.  In  this  respect,  the  integration  of  automatic  model  checking  procedures  such  as  pioneered  by.  N.  Shankar  for 
the  PVS  system  seems  particularly  promising.  ‘  " 

To  come  up  with  usable  solutions,  a  close  co-operation  with  interested  vendors,  users  and  evaluators  for  PLC  controllers  in 
safety  critical  fields  is  urgently  needed. 
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Abstract 

This  paper  describes  a  case  study  to  determine  whether 
computer-aided  prototyping  techniques  provide  a  cost- 
effective  means  for  re-engineering  legacy  software.  The 
case  study  consists  of  developing  a  high-level  modular 
architecture  for  the  existing  US  Army  Janus  combat 
simulation  system,  and  validating  the  architecture  via  an 
executable  prototype  using  the  Computer  Aided 
Prototyping  System  (CAPS),  a  research  tool  developed  at 
the  Naval  Postgraduate  School.  The  case  study  showed 
that  prototyping  can  be  a  valuable  aid  in  re-engineering 
of  legacy  systems,  particularly  in  cases  where  radical 
changes  to  system  conceptualization  and  software 
structure  are  needed  [1].  The  CAPS  system  enabled  us  to 
do  this  with  a  minimal  amount  of  coding  effort. 


1.  Introduction 

Re-engineering  is  typically  needed  when  a  system 
performing  a  valuable  service  must  change,  and  its 
current  implementation  can  no  longer  support  cost- 
effective  changes.  Such  legacy  systems  usually  lack 
accurate  documentation,  modular  structure,  and  coherent 
abstractions  that  correspond  to  current  or  projected 
requirements.  Past  optimizations  and  design  changes  have 
spread  design  decisions  that  must  be  changed  over  large 
areas  of  the  code.  The  main  objective  of  a  re-engineering 
effort  is  thus  to  develop  a  coherent  modular  architecture 
that  can  support  cost-effective  change  and  to  transform 
the  legacy  implementation  to  fit  into  the  new  architecture. 
The  Janus  system  fits  this  classical  situation. 

Janus(A)  is  a  software-based  war  game  that  simulates 
ground  battles  between  up  to  six  adversaries.  It  is  an 
interactive,  closed,  stochastic,  ground  combat  simulation 
with  color  graphics.  Janus  is  “interactive”  in  that 
command  and  control  functions  are  entered  by  military 
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analysts  who  decide  what  to  do  in  crucial  situations 
during  simulated  combat.  The  current  version  of  Janus 
operates  on  a  Hewlett  Packard  workstation  and  consists  of 
a  large  number  of  FORTRAN  modules,  organized  as  a 
flat  structure  and  interconnected  with  one  another  via 
FORTRAN  COMMON  blocks,  resulting  in  a  software 
structure  that  makes  modification  to  Janus  very  costly  and 
error-prone.  There  is  a  need  to  modernize  the  Janus 
software  into  a  maintainable  and  evolvable  system  and  to 
take  advantage  of  modem  Personal  Computers  to  make 
Janus  more  accessible  to  the  Army.  The  Software 
Engineering  group  at  the  Naval  Postgraduate  School  was 
tasked  to  extract  the  existing  functionality  through  reverse 
engineering  and  to  create  an  object-oriented  architecture 
that  supports  existing  and  required  enhancements  to  Janus 
functionality. 

2.  The  Re-engineering  Process 
2.1.  Reverse-Engineering 

The  first  step  in  reverse-engineering  is  system 
understanding.  Analysis  of  the  legacy  implementation  is  a 
daunting  but  inescapable  part  of  this  step.  If  printed  out  at 
60  lines  per  page,  350,000  lines  would  fill  almost  6000 
pages.  We  recoiled  from  the  magnitude  of  this  effort,  but 
in  hindsight,  this  was  a  mistake  that  slipped  the  schedule 
of  the  project  by  several  months.  Understanding  a  design 
of  this  complexity  requires  time  for  mental  digestion, 
even  with  tool  support  and  judicious  sampling.  We  should 
have  started  analysis  of  the  code  right  away  and  should 
have  persistently  continued  this  task  in  parallel  with  all 
other  re-engineering  activities.  Cross  fertilization  between 
all  the  tasks  would  have  helped  us  recognize  some  dead¬ 
end  directions  earlier  and  would  have  enabled  us  to  spend 
meeting  time  more  effectively.  However,  we  actually 
started  the  process  with  a  series  of  brief  meetings  with  the 
client,  TRAC-Monterey,  asking  questions  and  making 
notes  on  the  system’s  operation  and  its  current 
functionality.  We  paid  attention  to  the  client’s  view  of 
the  system  to  gather  their  ideas  on  its  strengths, 
weaknesses,  and  desired  and  undesired  functionality. 
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These  meeting  were  indispensable  because  they  gave  us 
information  that  was  not  present  in  the  code.  Additionally 
we  collected  copies  of  the  Janus  User’s  manual,  the  Janus 
Programmer’s  Manual,  the  Janus  Database  Management 
Program  Manual,  the  Janus  Software  Design  Manual,  and 
the  Janus  Algorithm  Document  [2,  5-8].  These  documents 
helped  us  get  started  because  they  contained  higher  level 
information  and  were  much  shorter  than  the  code.  They 
were  also  older,  and  it  was  a  constant  struggle  to 
determine  which  parts  were  still  accurate,  and  which  were 
not. 

Since  we  were  not  familiar  with  the  domain  of  ground 
combat  simulation,  we  were  using  these  meetings  to 
determine  the  requirements  of  this  domain,  often  playing 
the  role  of  “smart  ignoramuses”  [10].  Domain  analysis 
has  been  identified  as  an  effective  technique  for  software 
re-engineering  [11].  Our  experience  suggests  that 
competent  engineers  unfamiliar  with  die  application 
domain  have  an  essential  role  in  re-engineering  as  well  as 
in  requirements  elicitation  because  lack  of  inessential 
information  about  the  application  domain  makes  it  easier 
to  find  new,  simpler  design  structures  and  architectural 
concepts  to  guide  the  re-engineering  effort. 

The  next  step  is  to  abstract  the  system’s  functionality 
and  produce  system  models  that  would  most  accurately 
represent  that  functionality  [1].  Armed  with  the  Janus 
source  code,  we  proceeded  to  divide  the  code  by 
directories  amongst  the  team  members.  Each  team 
member  was  assigned  roughly  six  to  seven  directories  to 
explore,  examine  and  gather  information.  Using  manual 
techniques  augmented  with  UNIX  commands  and  review 
procedures,  we  were  able  to  get  a  fairly  good  idea  of  what 
each  subroutine  was  designed  to  do.  We  also  used  the 
Software  Programmers’  Manual  [5]  to  aid  in 
understanding  each  subroutine’s  function.  In  doing  so  we 
were  able  to  group  the  subroutines  by  functionality  to  get 
a  better  understanding  of  the  major  data  flows  between 
programs.  Using  that  knowledge,  we  developed 
functional  models  from  the  data  flows. 

We  used  the  Computer-Aided  Prototyping  System 
(CAPS)  [3,4],  an  automated  tool  developed  at  the  Naval 
Postgraduate  School,  to  assist  in  developing  the  abstract 
models.  CAPS  allowed  us  to  rapidly  graph  the  gathered 
data  and  transform  it  into  a  more  readable  and  usable 
format.  Additionally,  CAPS  enabled  us  to  concurrently 
develop  our  diagrams,  and  then  join  them  together  under 
the  CAPS  environment,  where  they  can  be  used  to 
generate  an  executable  model. 

Figure  1  shows  the  resultant  top-level  structure  of  the 
existing  Janus  system.  It  consists  of  five  subsystems 
cs_data_mgmt,  scenario _db,  jams,  jaaws,  and  postp.  The 
cs_data_mgmt  subsystem  manages  combat  system 
databases.  The  scenariojdb  subsystem  manages  the 
different  scenarios  and  simulation  runs  in  the  system.  The 


jams  subsystem  simulates  the  ground  battles.  The  jaaws 
subsystem  allows  analysts  to  perform  post-simulation 
analysis  and  the  postp  subsystem  allows  Janus  users  to 
view  simulation  reports. 

2.2.  Transformation  of  Functional  Models  to 
Object  Models 

Next,  we  developed  object  models  of  the  Janus  System 
using  the  aforementioned  materials  and  products,  to 
create  the  modules  and  associations  amongst  them. 
Information  modeling  is  needed  to  support  effective  re¬ 
engineering  of  complex  systems  [12].  This  was  probably 
the  most  difficult  and  most  important  step.  It  required  a 
great  deal  of  analysis  and  focus  to  transform  the  currently 
scattered  sets  of  data  and  functions  into  small,  coherent 
and  realizable  objects,  each  with  its  own  attributes  and 
operations.  In  performing  this  step,  we  used  our 
knowledge  of  object-oriented  analysis  and  applied  the 
OMT  techniques  and  the  UML  notations  to  create  the 
classes  and  associated  attributes  and  operations.  This  was 
a  crucial  step  because  we  had  to  ensure  that  the  classes  we 
created  accurately  represented  the  functions  and 
procedures  currently  in  the  software.  Restructuring 
software  to  identify  data  abstractions  is  a  difficult  part  of 
the  process.  Transformations  for  meaning-preserving 
restructuring  can  be  useful  if  tool  support  is  available 
[13].  We  used  the  HP-UNIX  systems  at  the  TRAC- 
Monterey  facility  to  run  the  Janus  simulation  software  to 
aid  in  verifying  and/or  supplementing  the  information  we 
obtained  from  reviewing  the  source  code  and 
documentation.  This  step  enabled  us  to  better  analyze  the 
simulation  system,  gaining  insight  into  its  functionality 
and  further  concentrate  on  module  definition  and 
refinement. 

2.3.  Refinement  and  Validation  of  the  Object 
Models 

During  this  phase  of  the  project,  the  re-engineering 
team  met  several  times  each  week  for  a  period  of  two  and 
a  half  months  to  discuss  the  object  models  for  the  Janus 
core  elements  and  the  object-oriented  architecture  for  the 
Janus  System.  They  presented  the  findings  to  the  Janus 
domain  experts  at  least  once  per  week  to  get  feedback  on 
the  models  and  architectures  being  constructed.  In 
addition,  the  re-engineering  team  also  presented  the 
findings  to  members  of  the  OneSAF  project,  the 
Combat21  project,  and  the  National  Simulation  Center. 
We  found  that  information  from  these  domain  experts 
was  essential  for  understanding  the  system,  particularly  in 
cases  where  the  legacy  code  did  not  correspond  to 
stakeholder  needs.  This  supports  the  hypothesis  advanced 
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in  [14]  that  the  involvement  of  domain  experts  is  critical 
for  nontrivial  re-engineering  tasks.  Based  on  the  feedback 
from  the  domain  experts,  the  re-engineering  team  revised 
the  object  models  for  the  Janus  core  elements  and 
developed  a  3-tier  object-oriented  architecture  for  the 
Janus  System  (Figure  2). 

3.  Software  Architecture  for  the  Janus 
Combat  Simulation  Subsystem 

Central  to  the  existing  Janus  Combat  Simulation 
Subsystem  is  the  program  RUNJAN,  which  is  the  main 
event  scheduler  for  the  Janus  simulation.  RUNJAN 
determines  the  next  scheduled  event  and  executes  that 
event.  If  the  next  scheduled  event  is  a  simulation  event, 
RUNJAN  will  advanced  the  game  clock  to  the  scheduled 
time  of  the  event  and  perform  that  event.  The  existing 
event  scheduler  uses  global  arrays  and  matrices  to 
maintain  the  attributes  of  the  objects  in  the  simulation. 
Hence,  one  of  the  major  tasks  in  designing  an  object- 
oriented  architecture  for  the  Janus  combat  simulation 
subsystem  was  to  distribute  the  event  handling  functions 
to  individual  objects.  Moreover,  it  was  necessary  to 
redefine  some  event  categories  in  order  to  provide  a 
uniform  framework  to  eliminate  redundant  coding  of  the 
same  or  similar  functions  and  to  take  advantage  of 
dynamic  dispatching  of  event  handling  functions  in  the 
object-oriented  architecture. 

Interactions  between  the  simulation  engine  and  the 
world  modeler  (the  distributed  simulation  network)  are 
performed  implicitly  within  the  various  event  handlers  in 
the  existing  Janus.  Such  interactions  are  made  explicit  in 
the  new  architecture  in  order  to  provide  a  uniform 
framework  to  update  World  Model  objects  during  the 
simulation. 

The  new  architecture  uses  an  explicit  priority  queue  of 
event  objects  to  schedule  the  simulation  events.  Each 
event  object  has  an  associated  simulation  object,  which  is 
the  target  of  the  event.  There  are  14  event  groups,  which 
correspond  to  the  14  event  subclasses  shown  in  Figure  3. 

An  object-oriented  approach  enabled  us  to  reduce  the 
number  of  event  types  needed  in  the  simulation. 
Depending  on  the  subclass  that  an  event  object  belongs 
to,  the  "execute"  method  will  invoke  the  corresponding 
event  handler  of  the  associated  simulation  object  to 
handle  the  event  (Figure  4).  The  simulation  object 
superclass  defines  the  interface  of  the  event  handlers  for 
the  event  groups,  and  provides  an  empty  body  as  the 
default  implementation  for  the  event  handlers.  The 
methods  are  overridden  by  the  actual  event  handler  code 
at  the  subclasses  that  have  non-empty  actions  associated 
with  the  events. 

The  above  architecture  enables  a  very  simple 


realization  of  the  main  simulation  loop: 
initialization; 

While  not_empty(event_queue)  loop 
e  ;=  remove _even t( even t  q ueue); 
e.execute(  ); 

End  loop; 
finalization; 

Note  that  this  same  code  handles  all  kinds  of  events, 
including  those  for  future  extensions  that  are  yet  to  be 
designed.  Event  objects  are  created  and  inserted  into  the 
event  queue  by  the  initialization  procedure  at  the 
beginning  of  the  simulation,  by  the  constructors  of  new 
simulation  objects,  and  by  the  actions  of  other  event 
handlers.  Depending  on  implementation  decisions 
regarding  when  and  how  events  are  inserted  into  the 
priority  event  queue,  it  may  be  necessary  to  allow  events 
to  change  their  priorities  while  waiting  in  the  queue. 

World  Model  object  subclasses  were  created  to 
provide  specialized  methods  for  the  world  modeler  to 
update  the  objects  from  other  simulators.  Information 
concerning  objects  local  to  the  Janus  simulator  can  be 
broadcast  over  the  simulation  network  either  periodically 
by  an  active  world  modeler  object,  or  by  individual  local 
objects  whenever  they  update  their  own  states. 

4.  Development  of  an  Executable  Prototype 
Using  CAPS 

In  order  to  validate  the  proposed  architecture  and  to 
refine  the  interfaces  of  the  Janus  subsystems,  we 
developed  an  executable  prototype  using  CAPS.  Figure  5 
shows  the  top-level  structure  of  the  prototype,  which  has 
four  subsystems:  Janus,  GUI,  JAAWS  and  the  POST¬ 
PROCESSOR.  Among  these  four  subsystems,  the  Janus 
and  the  GUI  subsystems  (depicted  as  double  circles)  are 
made  up  of  sub-modules  shown  in  Figures  6  and  7,  while 
the  JAAWS  and  the  POST-PROCESSOR  subsystems 
(depicted  as  single  circles)  are  mapped  directly  to  objects 
in  the  target  language.  After  we  entered  the  prototype 
design  into  CAPS,  we  used  the  CAPS  execution  support 
system  to  generate  the  code  that  interconnects  and 
controls  these  subsystems. 

Due  to  time  and  resource  limitations,  we  only 
developed  the  prototype  for  a  very  small  simulation  run, 
which  consists  of  a  single  object  (a  tank)  moving  on  a 
two-dimensional  plane,  three  event  subclasses  (move, 
do_plan,  and  end_simulation),  and  one  kind  of  post¬ 
processing  statistics  (fuel  consumption).  In  addition,  a 
simple  user  interface  was  developed  using  CAPS/TAE  [9] 
(Figure  8).  The  resultant  prototype  has  over  6000  lines  of 
program  source  code,  most  of  which  was  automatically 
generated,  and  contains  enough  features  to  exercise  all 
parts  of  the  architecture.  The  code  that  handles  the  motion 
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of  a  generic  simulation  object  was  very  simple,  but  it  was 
designed  so  that  it  would  work  in  both  two  and  three 
dimensions  without  modification  (currently  the 
initialization  and  the  movement  plan  of  the  tank  object 
never  call  for  any  vertical  motion).  The  code  was  also 
designed  to  be  polymorphic,  just  as  was  the  main  event 
loop.  This  means  the  same  code  will  handle  the  motion  of 
all  kinds  of  simulation  objects  without  any  modifications, 
including  new  types  of  simulation  objects  that  are  part  of 
future  enhancements  to  Janus  and  have  not  yet  been 
designed  or  implemented. 

5.  Lessons  Learned 

Our  prototyping  experiment  showed  that  the  proposed 
object-oriented  architecture  allows  design  issues  to  be 
localized  and  provides  easy  means  for  future  extensions. 
We  started  out  with  a  prototype  consisting  of  only  two 
events  subclasses  (move  and  end_simulation)  and  were 
able  to  add  a  third  event  subclass  (do_plan)  to  the 
prototype  without  modifying  the  event  control  loop  of  the 
Janus  combat  simulator. 

We  also  demonstrated  the  use  of  inheritance  and 
polymorphism  to  efficiently  extend/specialize  the 
behavior  of  combat  units.  For  example,  to  implement  the 
mo ve_update_obj ect  method  of  a  tank  subclass  which 
uses  the  general-purpose  method  from  its  superclass  to 
compute  its  distance  traveled  and  a  specialized  algorithm 
to  compute  its  fuel  consumption,  we  simply  include  1 
statement  to  invoke  the  mo ve_up date__obj  ect  method  of 
its  superclass  followed  by  three  lines  of  code  to  update  its 
fuel  consumption.  Moreover,  other  combat  unit 
subclasses  can  be  added  easily  to  the  prototype  without 
the  need  to  modify  the  event  scheduling/dispatching  code 
and  usually  without  modifying  existing  event  handlers. 

The  prototype  also  resulted  in  the  following 
refinements  to  the  proposed  architecture: 

(1)  Instead  of  a  procedure  with  no  return  value,  change 
the  ExecuteJEvent  operation  to  return  the  time  at 
which  the  next  event  is  to  be  scheduled  for  the  same 
simulation  object,  and  introduce  a  special  time  value 
"NEVER"  to  indicate  that  no  next  event  is  needed. 
The  proposed  change  turns  the  communication 
between  the  event  dispatcher  and  the  simulation 
objects  from  a  peer-to-peer  communication  into  a 
client-server  communication.  This  change  eliminates 
the  need  for  the  simulation  objects  to  know  the  details 
of  the  event  queue  and  allows  the  event  dispatcher  to 
use  a  single  statement  to  schedule  all  recurring  events 
for  all  event  types. 

(2)  Instead  of  recording  the  history  of  a  simulation  run  in 
terms  of  sets  of  data  files,  model  the  simulation 
history  as  a  sequence  of  events.  The  proposed  change 


provides  a  simple  and  uniform  way  to  handle  history 
records  for  all  events,  and  allows  the  same  modular 
architecture  to  be  used  for  real-time  simulations  as 
well  as  post-simulation  analysis.  It  also  eliminates  the 
need  for  the  write-status  event  in  the  legacy  software. 
This  approach  provides  the  greatest  possible 
resolution  for  the  event  histories,  which  implies  that 
any  quantity  that  could  have  been  calculated  during 
the  simulation  can  also  be  calculated  by  a  post¬ 
simulation  analysis  of  the  event  history,  without  any 
loss  of  accuracy.  The  only  constraint  imposed  by  this 
design  refinement  is  that  the  simulation  objects  in  the 
events  must  be  copied  before  being  included  in  the 
simulation  history,  to  protect  them  from  further 
changes  of  state  as  the  simulation  proceeds.  This 
constraint  is  easy  to  meet  in  a  full-scale 
implementation  because  the  process  of  writing  the 
contents  of  an  event  object  to  a  history  file  will 
implicitly  make  the  required  copy. 

The  prototyping  effort  also  exposed  a  design  issue  - 
should  null  events  appear  in  the  event  queue?  A*  null 
event  is  one  that  does  not  affect  the  state  of  the 
simulation,  such  as  a  move  event  for  an  object  that  is 
currently  stationary.  The  prototype  version  adopted  the 
position  that  such  events  should  not  be  put  in  the  event 
queue,  since  this  corresponds  to  current  scheduling 
policies  in  Janus,  and  appears  at  first  glance  to  improve 
efficiency. 

Our  experience  with  the  development  of  the  prototype 
suggests  that  this  decision  complicates  the  logic  and  may 
not  in  fact  improve  efficiency.  In  particular,  the  process 
create_new_events  (see  Figure  6)  could  be  eliminated  if 
we  allowed  null  events.  This  process  scans  all  simulation 
objects  once  per  simulation  cycle  to  determine  if  any 
dormant  objects  have  become  active,  and  if  so,  schedules 
events  to  handle  their  new  activity.  The  alternative  is  to 
have  the  constructor  of  each  kind  of  simulation  object 
schedule  all  of  its  initial  events,  and  to  have  each  event 
handler  specify  the  time  of  next  instance  of  the  same 
event  even  if  there  is  nothing  for  it  to  do  currently. 
Handlers  might  still  set  the  time  of  its  next  event  to 
NEVER  in  the  case  of  a  catastrophic  kill;  however  this  is 
reasonable  only  if  it  is  impossible  to  repair  or  restore  the 
operation  of  the  units  that  have  suffered  a  catastrophic 
kill. 

The  reasons  why  this  design  change  may  improve 
efficiency  in  addition  to  simplifying  the  code  are  that: 

(1)  the  check  for  whether  a  dormant  object  has  become 
active  is  done  less  often  -  once  per  activity  of  that 
object,  rather  than  once  per  simulation  cycle, 

(2)  executing  a  null  event  is  very  fast  -  a  few  instructions 
at  most,  so  the  “unnecessary”  null  events  will  not  have 
much  impact  on  execution  time,  and 

(3)  the  computation  to  find  and  test  all  simulation  objects 
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periodically  would  be  eliminated. 

One  recommendation  is  to  allow  null  events  in  the 
event  queue,  and  to  explicitly  schedule  every  kind  of 
event  for  every  object  unless  it  is  known  that  there  cannot 
be  any  non-empty  events  of  that  type  in  any  possible  state 
of  the  object.  For  example,  under  the  proposed  scheduling 
policy,  immobile  or  irrecoverably  damaged  objects  would 
not  need  to  schedule  future  move  events,  but  those  that 
are  currently  at  their  planned  positions  would  need  to  do 
so,  because  a  change  of  plan  would  cause  them  to  move 
again  in  the  future,  even  though  they  are  not  currently 
moving. 

6.  Conclusion 

Our  experience  in  this  case  study  suggests  that 
prototyping  can  be  a  valuable  aid  in  re-engineering  of 
legacy  systems,  particularly  in  cases  where  radical 
changes  to  system  conceptualization  and  software 
structure  are  needed. 

In  particular,  we  found  that  constructing  even  a  very 
thin  skeletal  instance  of  the  proposed  new  architecture 
raised  many  issues  and  enabled  us  to  correct,  complete, 
and  optimize  the  architecture  for  both  simplicity  and 
performance. 

The  computer-aided  prototyping  tools  in  the  CAPS 
system  enabled  us  to  do  this  with  a  minimal  amount  of 
coding  effort.  The  bulk  of  the  code  was  generated 
automatically,  enabling  us  to  concentrate  on  system 
structuring  issues,  to  consider  and  evaluate  various 
alternatives,  and  to  improve  the  design  while  doing 
detailed  manual  implementation  for  only  a  few  pages  of 
critical  code.  Our  experience  corroborates  the  ideas  that 
re-engineering  is  the  combination  of  reverse  engineering 
with  forward  engineering  [15]  and  that  the  most  useful 
representations  for  the  information  extracted  via  reverse 
engineering  are  those  that  can  drive  tools  for  forward 
engineering. 
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Figure  1.  Top-level  communication  structure  of  the  existing  Janus  software 
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Figure  2.  The  proposed  3-tier  object-oriented  architecture. 
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Figure  3.  The  event  class  hierarchy  showing  the  different  event  handling  operations  of  the  JANUS 
Combat  Simulation  Subsystem. 


Figure  4.  The  simulation  object  class  hierarchy  showing  the  distribution  of  the  event 
operations. 
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Figure  6.  The  JANUS  subsystem  of  the  executable  prototype 
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Figure  7.  The  GUI  subsystem  of  the  executable  prototype 


Figure  8.  The  Graphical  User  Interface  of  the  executable  prototype 
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Abstract 

The  application  of  multimedia  transmission  has  as  one  of  its  predominate  components  network 
communications.  I  have  endeavored  to  implement  and  analyze  network  communication  of  multimedia 
information.  In  this  analysis  Xpress  Transfer  Protocol  and  Fiber  Distributed  Data  Interface  protocol  have 
been  utilized.  This  combination  has  provided  a  high  speed  and  high  performance  network  solution  to  the 
multimedia  transmission  that  requires  high  bandwidth.  FDDI  is  an  implementation  of  the  ISO  standard  for 
Open  Systems  Interconnect  (OSI)  Reference  Model  Data-Link  and  Physical  layer  protocols.  These  protocol 
implementations  afford  us  a  signaling  rate  of  100  Mbits/sec  in  addition  to  fault  tolerance.  XTP  in  an 
implementation  of  both  the  Transport  and  Network  layers  within  the  OSI  Reference  Model.  The  basis  of 
this  XTP  implementations  design  is  for  high  performance  and  efficiency.  Employing  this  protocol  I  have 
successfully  implemented  both  Unicast  and  Multicast  network  communication  modes.  The  results  of  these 
implementations  are  presented  in  this  paper. 


Introduction 

Multimedia  (voice,  video,  data,  text,  and  graphics)  distribution  over  high  speed  networks  has 
many  commercial  applications  which  has  revolutionize  the  way  computers  and  networks  are  used. 
Numerous  commercial  entities  have  formed  strategic  alliances  to  explore  new  opportunities  in  this  area.  I 
have  been  experimenting  for  several  years  with  high  speed  networks  which  utilize  FDDI,  and  a  high 
performance  network  protocol  called  Xpress  Transfer  Protocol.  I  have  performed  many  voice/video 
transmission  experiments  using  XTP  with  several  machines  connected  via  FDDI  network.  The  results 
indicate  voice  and  video  transmission  using  XTP  and  FDDI  has  many  advantages  over  traditional  methods 
of  transmission  including  fault  tolerance,  high  bandwidth,  and  data  integration. 

Xpress  Transport  Protocol 

Xpress  Transport  Protocol  is  an  implementation  of  the  Open  Systems  Interconnect  (OSI) 
Reference  Model  layers  3  and  4,  or  Network  and  Transport  respectively.  XTP  allows  for  extensive 
application  control  over  the  network  interface.  Within  the  design  of  XTP  full  advantage  is  taken  of  the  low 
Bit  Error  Rate  (BER)  offered  by  current  network  media  such  as  fiber  optics.  This  reduction  in  error 
processing  allows  a  shift  to  the  focus  of  completing  other  tasks. 

XTP  notability  also  includes  improvements  over  other  protocols]!]:  Data  Pipeline  Size;  Rate 
Control;  Priorities;  Out-of-band  Data;  No-error  Mode;  Policy  Vs  Mechanism;  Multicast;  Header/Trailer 
Protocol;  Fixed-length  Fields;  Efficient  Connection  Setup  and  Teardown;  Address  Translation  Routing; 
Retransmission;  Acknowledged  Control;  Alignment;  and  VLSI  Implementation  When  compared  to 
traditional  protocols  XTP  offers  various  functional  enhancements.  XTP  provides  a  pipeline  design  which 
can  accompany  megabit  and  gigabit  networks  (easily  upgraded  to  terabit).  Rate  and  burst  control  are 
accessible  via  parameters  with  the  rate  bits  capable  of  being  controlled  at  the  receive  side  for 
synchronization  purposes.  Prioritization  provides  for  user  data  discrimination.  Policy  vs  mechanism  being 
a  primary  design  philosophy  behind  XTP  allows  user  level  control  of  implementation  instead  of  fixed  pre- 
established  policies,  an  example  of  this  is  the  no-error  mode  setting.  Multicast  also  provides  a  functional 
enhancement  over  common  protocols  by  providing  semi-reliability  of  the  network  session.  Additionally 
XTP  has  added  features  which  focus  upon  performance.  The  addition  of  a  header/trailer  instead  of  the 
traditional  header  in  a  data  packet  allows  for  checksum  to  be  calculated  and  appended  thus  reducing  one 
sequential  data  pass.  Fixed-length  fields  (i.e.  header/trailer  and  flags)  provides  added  efficiency. 
Connection  setup/teardown  for  reliable  transmission  requires  only  two  packets  (vs  TP4  six  packets)  in 
addition  to  providing  various  connection  release  paradigm  support.  XTP  addressing  translation  provides 
for  interoperability  of  Internet  Protocol  (IP)  and  ISO  8348  as  well  as  many  other  network  addressing 
designs.  As  XTP  has  implemented  the  Network  layer  protocol  it  supports  routing  also  by  bridging  the 
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Transport/Network  layers  is  has  established  a  “transfer  layer”  architecture  this  routing  has  added 
efficiency.  XTP  provides  selective  retransmission  when  reliable-service/error-detection  mode  is  desired. 
Elective  acknowledgment  control  is  also  provided  to  the  user  by  XTP. 

Recent  work  within  the  XTP  community  is  focused  upon  integration  with  the  IP  which  resides  on 
the  OSI  Reference  Model  Network  layer.  This  number  3  layer  provides  the  necessary  routing  between 
network  segments.  The  integration  of  XTP  with  IP  would  greatly  enhance  XTP’s  implementation 
capabilities  .  Given  the  numerous  IP  based  routers  currently  in  use  around  the  world  this  link-up  between  , 
the  two  protocols  would  provide  obvious  advantages.  The  utilization  of  an  enhanced  Transport  layer 
protocol  such  as  XTP  in  combination  with  the  popularly  employed  IP  Network  layer  protocol  will  allow 
application  specific  network  communication  over  Wide  Area  Network  (WAN). 

Fiber  Distributed  Data  Interface 

The  Fiber  Distributed  Data  Interface  (FDDI)  is  an  ANSI  standard  based  on  timed-token  protocol 
technology.  Within  the  OSI  Reference  Model  FDDI  implements  a  version  of  Physical  and  Data  Link  layers 
1&2.  A  typical  network  consists  of  nodes  connected  by  two  fiber  cables  with  a  logical  token  circulating 
among  the  nodes  and  a  signaling  rate  of  100  Mbits/sec.  The  FDDI  architecture  is  to  varying  degrees  fault 
tolerant.  The  network  topology  in  our  testbed  will  remain  operational  if  a  single  fault,  such  as  a  cable 
break,  occurs.  The  FDDI  features  that  are  useful  in  the  transmission  of  voice  and  video  are:  High 
bandwidth  (100  Mbit/sec);  Very  low  error  rates  (10'^  BER);  Predictable  token  access  (low  jitter);  Large 
packet  size  (4500  bytes).  Other  characteristics  of  FDDI  that  serve  practical  purposes  are:  Fault  tolerance; 

No  electromagnetic  emissions/interference;  and  Notion  of  priority. 

Testbed  Experiments 

Our  testbed  consists  of  several  commercially  available  Intel  based  PCs  containing  off-the-shelf 
components.  Each  network  node  PC  is  populated  with  Dual  Attached  Station  FDDI  cards,  10-bit  resolution 
audio  analog-digital  converter  cards  using  Adaptive  Differential  Pulse  Code  Modulation  (ADPCM)  audio 
compression  with  16  kHz  sample  rate,  and  2-card  set  of  video  interface  boards  consisting  of  JPEG  video 
compression  hardware  and  frame  grabber  engine  which  perform  the  digital  video  capturing  and 
compression  functions.  All  PCs  are  connected  by  a  dual  ring  fiber  optic  cable. 

The  experiments  follow  two  basic  sequences  of  operation.  The  primary  operation  occurs  on  the 
transmitting  side  of  the  network  communication  connection.  First  task  is  to  obtain  video  or  audio  analog 
data  and  to  perform  analog-to-digital  conversion.  Once  completed  this  digitized  information  is  then 
compressed  using  the  appropriate  data  compression  algorithm  with  the  respective  VLSI  chipset  (ADPCM 
for  audio  and  JPEG  for  video)  residing  on  the  hardware.  The  compressed  data  is  then  formed  into  XTP 
network  packets,  by  the  application  and  XTP  software,  for  transmission  over  the  Fiber  Optic  network  via 
the  FDDI  hardware  in  the  node.  The  second  set  of  operations  is  performed  at  the  receiving  node,  beginning 
with  the  receipt  by  the  Fiber  Optic  network  and  FDDI  hardware  in  the  node.  These  FDDI  frames  are 
processed  by  XTP  and  the  resulting  compressed  data  is  delivered  to  the  appropriate  hardware  for 
decompression  and  the  resulting  data  is  output  to  either  the  screen  in  the  case  of  video  data  or  the  speaker 
in  the  case  of  audio  data.  This  completes  the  communication  cycle. 

Audio  Transmission 

During  the  course  of  our  audio  experiments  latency  measurements  were  taken  periodically.  This 
measured  latency  was  indicative  of  the  time  required  for  end  to  end  (i.e.  microphone-speaker)  transmission. 
The  results  indicated  a  latency  of  approximately  25ms,  which  was  well  within  the  tolerable  limits  of 
perception  by  the  human  ear. 


One-Way  Delay 

Effect  of  delay 

>600ms 

Incoherent 

600ms 

Barely  Coherent 

250ms 

Annoying 

100ms 

Imperceptible  (without  network/original  sample  comparison) 

50ms 

Imperceptible  (with  network/original  sample  comparison) 

Table  1:  Effects  of  latency  on  human  ear  perception[3] 
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The  latency  tests  were  based  upon  XTP  unicast  mode  communication  link  sending  XTP  network 
packets  sized  at  50  bytes  each,  and  A/D  converter  buffered  by  an  array  of  bytes  1024  long.  This  schema 
provided  a  good  basis  for  testing  and  analysis.  The  ADPCM  audio  compression  algorithm  compresses  the 
sampled  audio  waveform  to  4  bits  thereby  reducing  the  data  size  by  over  50%  compared  to  10  bit  PCM 
digitization.  This  compression  allows  for  very  low  network  bandwidth  utilization.  When  operating  in 
unicast  mode,  the  average  consumption  of  network  bandwidth  given  a  typical  compressed  audio  packet  is 
.5035  Mbits/sec.  XTP  unicast  mode  is  a  network  communication  utilizing  2  nodes,  where  one  node  acts  as 
a  transmitter  and  another  node  acts  as  a  receiver.  This  bandwidth  is  increased  to  approximately  1.102 
Mbits/sec  when  utilizing  duplex  mode  communication.  XTP  duplex  mode  involves  two  nodes  and  each 
node  acts  as  transmitter  and  receiver  simultaneously. 

Video  Transmission 

The  realtime  video  originated  from  various  sources  such  as:  Cable  News  Network  (CNN) 
broadcast  acquired  from  satellite  downlink;  Video  Camera;  and  Video  Tape.  These  sources  all  followed  the 
NTSC  format  and  all  were  fed  into  the  video  frame  grabber.  Again,  during  our  experiments,  latency 
measurements  were  recorded  periodically.  This  time  the  measured  latency  was  representative  of  the  time 
required  for  picture  to  picture  (i.e.  screen  display  to  screen  display)  transmission.  The  outcome  of  these 
tests  revealed  a  latency  of  approximately  50-60ms  (less  than  2  frames)  given  that  our  experiments  were 
based  upon  utilizing  NTSC  standard  input  which  is  30  fps.  This  small  latency  is  very  difficult  to  perceive, 
even  with  the  source  and  destination  display  screens  side  by  side.  Table  2  represents  some  results  of  a 
study  [3]  on  frame  rates  and  their  effects  on  human  eyes.  As  can  be  seen,  a  jerky  motion  is  perceived  when 
successive  frames  are  67-83  ms  apart.  This  is  in  excess  of  the  latency  in  our  experiment  between  a  frame 
appearing  on  the  source  screen  and  the  same  frame  appearing  on  the  destination  screen. 


Frames  per  second 

Effect  on  human  eye 

<10  fps 

Frames  appear  disjoint 

12-15  fps 

Motion  is  jerky. 

30  fps 

Television  quality 

60-75  fps 

High-motion  discernible  (HDTV) 

90  fps 

Limit  of  human  eye  perception 

Table  2:  Effects  of  frame  rate  on  human  eye  perception  [3] 


These  latency  tests  were  also  based  upon  XTP  unicast  mode  communication  link  with  XTP 
network  packets  sized  at  3305  bytes  each,  and  a  video  buffer  of  16000  bytes.  The  JPEG  video  compression 
chipset  utilizing  the  Huffman  encoding  scheme  provided  us  with  2  to  4  times  data  reduction  thus  greatly 
reducing  the  network  bandwidth  requirements  for  our  realtime  video  communication  experiments.  A 
typical  XTP  unicast  communication  session  utilized  approximately  3  Mbits/sec  to  6  Mbits/sec  bandwidth. 
The  XTP  multicast  sessions  were  recorded  to  also  within  the  3  Mbits/sec  to  6  Mbits/sec  range  of  network 
bandwidth  consumption. 

Conclusion 

After  performing  the  audio  and  video  experiments  in  our  testbed,  the  results  have  indicated  the 
use  of  XTP  and  FDDI  on  multimedia  transmission  is  feasible  and  may  provide  a  bridge  to  the  giga-bit 
network  rates.  The  results  of  the  XTP  multicast  bandwidth  consumption  is  revealing  in  that  it  is  within  the 
range  of  the  typical  XTP  unicast  network  utilization  despite  the  fact  that  unicast  is  a  1  to  1  session  and 
multicast  is  1  to  N  network  communication  As  multimedia  is  becoming  an  important  industry  today,  more 
research  in  multimedia  transmission  is  needed. 
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